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(57) ABSTRACT 

A system and method for a packet Voice Response Unit 
(VRU) which directly utilize packet network protocols, such 
as those of the H.323 standard, to provide enhanced services 
via a packet network. The packet VRU generally operates 
within the packet network and is not required to provide data 
format translation or multiple device-type access. The 
packet VRU may be built entirely in software running on a 
network server with a standard packet network connection 
such as Ethernet or token-ring. In a preferred embodiment of 
the present invention, the packet VRU redirects the media 
stream from a source so that it is sent directly to a 
destination, instead of passing through the packet VRU. 
Alternatively, if the packet VRU must perform processing 
on the message contents, the packets may be sent to both the 
destination and to the packet VRU. The packet VRU may 
still retain call control over the media streams by maintain- 
ing the signaling and user input components of the call. In 
another preferred embodiment of the present invention, a 
gateway may convert user input indication signals received 
from a party connected via the gateway into user input 
indication messages in an out-of-band channel to be read by 
the packet VRU, separate from the redirected media streams. 
The packet VRU may generally provide the existing 
enhanced services of a synchronous VRU but in a packet 
network environment, and in addition provide enhanced 
services for multimedia communications. 

223 Claims, 10 Drawing Sheets 
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SYSTEM AND METHOD FOR PACKET 
NETWORK MEDIA REDIRECTION 

RELATED APPLICATIONS 

This application is related to the following commonly 
assigned, co-pending patent applications: Ser. No. 08/719, 
163, entitled INTERACTIVE INFORMATION TRANS- 
ACTION PROCESSING SYSTEM WITH UNIVERSAL 
TELEPHONY GATEWAY CAPABILITIES, by Michael 1Q 
Polcyn, filed Sep. 24, 1996; Ser. No. 08/846,961, entitled 
SWITCH LESS CALL PROCESSING, by Ellis Cave, filed 
Apr. 29, 1997; and Ser. No. 09/163,234, entitled INTER- 
ACTIVE INFORMATION TRANSACTION PROCESS- 
ING SYSTEM ON IP TELEPHONY PLATFORM, by 15 
Michael Polcyn, filed Sep. 29, 1998, which is a continuation 
of application Ser. No. 08/719,163; all of which applications 
are incorporated herein by reference. 

TECHNICAL FIELD 2Q 

This invention relates generally to a system and method 
for facilitating the transfer of information via an asynchro- 
nous packet network, and more particularly to a system and 
method for redirecting media in an asynchronous packet 
network. 25 

BACKGROUND 

Voice Response Units (" VRUs") have existed in the prior 
art for many years, and are generally defined as robotic 3Q 
systems that automatically interact with one o r more 
persons for the exchange of information and the enhance- 
ment of communications. There are numerous enhanced 
services capable of being provided by a VRU, including 
voice messaging, automated collect calling, international 3S 
callback, prepaid & postpaid calling card, store & forward, 
one number service, find me, follow me, 800/900 service, 
automated customer service, automated agents or attendants, 
voice activated dialing, prepaid & postpaid wireless, 
conferencing, and other such enhanced services. ^ 

In the prior art, synchronously switched VRUs were 
initially connected to the Plain Old Telephone system 
("POTS") network (i.e., the Public Switched Telephone 
Network ("PSTN")) via analog interfaces. Although POTS 
analog connections still exist, the use of digitized voice 45 
transmissions is becoming increasingly common on the 
PSTN. Because of the advantages of digitized transmission, 
a synchronous VRU is now typically connected to the POTS 
network via a digital interface, as disclosed in co-assigned 
U.S. Pat. No. 5,818,912, entitled FULLY DIGITAL CALL 50 
PROCESSING PLATFORM, by Daniel Hammond, issued 
Oct. 6, 1998, which application is incorporated herein by 
reference. An example of such a VRU is shown in FIG. 1, 
wherein synchronous VRU 100 is digitally connected to 
PSTN 102 via Tl trunk 104 using a standard Integrated 55 
Services Digital Network ("ISDN") format. Digitized voice 
signals transmitted over the PSTN normally consume 
approximately 64 Kilobits-per-second ("Kbps") of band- 
width when digitized and encoded according to the G.711 
compressed format using pulse code modulation ("PCM") 60 
and the standard /4-law or A-law logarithmic algorithms. 

Generally, in the prior art, the PSTN was originally 
designed to be managed and controlled by a single entity, 
and later developed such that very few entities control the 
primary switches that make up the network infrastructure. 65 
Generally, because control of the network is centered inside 
the PSTN switches and because the PSTN switches are of a 
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proprietary nature, very little control over the switching 
mechanisms is available to other entities that do Dot own the 
switches in the network. For example, each specific con- 
nection made by VRU 100, e.g., to telephone 106a, gener- 
ally requires its own port and a 64 Kbps channel. If the 
enhanced service being provided by VRU 100 requires 
connecting telephone 106a to another device external to 
VRU 100, for example to telephone 106c, there are limited 
options available to VRU 100, each with its own tradeoffs as 
explained below. 

First, PSTN 102 may transfer a call via Release Link 
Trunking ("RLT") by sending control signals to a switch in 
the network. For example, a calling party using telephone 
106a may wish to call another party at telephone 106c using 
an 800 calling card service provided by VRU 100. After the 
calling party enters a Card Number, personal identification 
number ("PIN") and the phone number for telephone 106c, 
VRU 100 verifies the information and then connects the two 
parties using RLT via PSTN 102. In using RLT, VRU 100 
gives up control of the call to PSTN 102, although VRU 100 
may send the customer's card number and PIN to PSTN 102 
for tracking purposes. Generally, a useful and desirable 800 
calling card service feature known as call re-origination 
allows the calling party to disconnect from the called party 
and reconnect to another called party without breaking the 
calling party's initial connection. Typically, the calling party 
on telephone 106a may hold down the # key for more than 
two seconds to signal to the network the calling party's 
desire to make a new call, although many other signals and 
durations may be used. Because VRU 100 has relinquished 
control of the call to PSTN 102, PSTN 102 must monitor the 
call for the # key dual-tone multi-frequency ("DTMF") 
signal so that PSTN 102 may then reconnect the calling 
party on telephone 106a to VRU 100. PSTN 102 also sends 
the customer ID and PIN back to VRU 100 so that the 
customer does not have to reenter this information. This 
approach has the advantage of freeing up the VRU ports for 
other callers, but it requires PSTN 102 to have an application 
running for tracking the customer's ID and PIN, and fbr 
monitoring the call for DTMF signals. 

Second, a user such as VRU 100 may use a hook flash to 
request that PSTN 102 directly connect telephone 106a to 
telephone 106c. This also has the advantage of freeing up 
ports on VRU 100, but VRU 100 permanently loses the call 
context Unlike RLT, the hook flash does not allow VRU 100 
to retrieve the call context from PSTN 102. The VRU then 
cannot perform important call control or administrative 
functions such as monitoring, recording, timing, or charging 
for the phone call. Because the call context is lost for VRU 
100, the calling party generally must reenter the Card 
Number and PIN, in addition to the new destination phone 
number, and VRU 100 must re- verify the calling party's 
information. Reentering these numbers can be frustrating to 
customers, and consumes extra connection time and pro- 
cessing resources. 

Alternatively, the connection between the two parties may 
be bridged between the telephones within VRU 100. Internal 
synchronous switch 112 and another port and 64 Kbps 
channel are required to complete the connection to telephone 
106c. VRU 100 does not relinquish control of the call to 
PSTN 102, so VRU 100 may still perform call control and 
administrative functions. In addition, VRU 100 may monitor 
the call for DTMF signals. If in the calling party using an 
800 calling card service wishes to make another call, the 
calling party may hold the # key for more than two seconds. 
VRU 100 detects this signal directly, and can disconnect the 
called party on one port from the calling party on the other 
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port. Because VRU 100 maintained the call context, the 
calling party's Card Number and PIN do not have to be 
reentered and re-verified. The calling party may simply enter 
the new destination phone number, and VRU 100 may then 
set up a new connection using another port. However, this 
alternative requires VRU 100 to implement internal switch 
112, and uses two circuits in the network and two ports on 
VRU 100, one for each party. Thus the VRU ports generally 
stay engaged for the entire duration of the phone call, instead 
of being made available for use on other phone calls. This is 
undesirable because unlike a simple switch, VRU ports are 
generally expensive resources that provide enhanced 
functions, such as voice recognition, DTMF detection/ 
generation or text-to-speech conversion, for interacting with 
callers. Normally, the network owners would like to always 
keep the VRU port busy handling new calls. However, since 
the VRU ports ate used to access the internal switch, the 
VRU ports are engaged during the entire call, even though 
the port is idle. 

In addition to internal switch 112 and extra network 
bandwidth used, a VRU bridged connection may also travel 
over an inordinate amount of distance. For example, a 
calling party in Houston, Tex., may wish to call another 
party in New Orleans, La,, using an 800 calling card service 
provided by a VRU. If the VRU is located in either of those 
cities, then the bridged call does not travel much extra 
distance compared to the physical distance between the 
actual parties. If the VRU is located in Los Angeles, Calif., 
however, the inbound call to the VRU must travel all the way 
to Los Angeles from Houston, and the outbound call from 
the VRU must travel all the way to New Orleans from Los 
Angeles, which is an inefficient use of network resources. 

Other problems with synchronously switched networks 
exist. They generally are expensive to build, difficult to 
upgrade once built, and not flexible enough to support new 
multimedia services. In response to these difficulties, along 
with other factors, there has been a dramatic increase in 
recent years of the availability of public packet networks, 
such as the Internet, other wide area networks ("WANs"), 
and local area networks ("LANs"), to exchange information, 
for example, in voice format. PSTN circuits generally mul- 
tiplex digitized voice signals by allocating sequential bits or 
words in separate conversations to periodic time slots in a 
time division multiple access ("TDMA") structure. The 
PSTN requires a switched architecture and point-to-point 
connections, and the data is transmitted continuously, so 
PSTN connections use up bandwidth needlessly when 
voices are silent during a call. On the other hand, packet 
networks asynchronously send digitized signals in pack- 
etized form, where each packet is encoded with a header that 
references its destination and sequence. The packets are only 
sent when there is information to send, thus packet networks 
do not need to send packets when the callers' voices are 
silent, saving bandwidth. 

In a packet network, the packets may follow one of many 
possible pathways to their destinations before they are 
reassembled, according to their headers, into a conversation. 
Generally, this has the disadvantage over the POTS/TDMA 
method in that the packet headers consume additional band- 
width. The packet header disadvantage is generally believed 
to be outweighed by the efficiencies in network usage 
without switched architecture and point-to-point connec- 
tions because, for example, a synchronous network continu- 
ously uses the same bandwidth even if there is no substan- 
tive signal to transmit. 

In part to promote interoperability in the fast developing 
packet network technology area, the International Telecom- 
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munications Union ("ITU"), located in Geneva, Switzerland 
and with a World Wide Web ("WWW") site of "bttp:// 
www.itu.org," has developed the H.323 standard for real- 
time multimedia (defined herein as including voice, video, 

5 data, or any combination thereof) communications and 
conferencing for packet -based networks. The H.323 
standard, entitled "Packet-based Multimedia Communica- 
tions Systems," released February 1998, is incorporated 
herein by reference, and is actually an umbrella standard for 

10 a series of specifications that describe how multimedia 
communications occur between terminals, network equip- 
ment and services on packet networks (e.g., Internet Proto- 
col ("IF') networks), some of which do not provide a 
guaranteed Quality of Service ("QoS"). The standard is 

1S based on the Internet Engineering Task Force ("IETF') 
real-time protocol ("RTP") and real-time control protocol 
("RTCF'), with additional protocols for call signaling and 
data and audiovisual communications. Another protocol, the 
resource reservation protocol ("RSVP"), may be imple- 

20 mented in routers to establish and maintain requested trans- 
mission paths and QoS levels. Generally, a protocol that 
guarantees a QoS level has mechanisms for ensuring the 
on-time delivery of traffic signals, recovering lost packets, 
and guaranteeing bandwidth availability for specific appli- 

25 cations. 

Some of the specifications referenced by the H.323 stan- 
dard include call control and framing specifications, such as 
H.225, Q.931, and H.245, audio codec specifications, such 
as G.711 for high bit rate connections and G.723 for 

30 low-bit-rate connections, video codec specifications, such as 
H.261 for high bit rate connections and H.263 for low-bit- 
rate connections, and data communications specifications, 
such as T.120 standards. The H.323 standard defines several 
entities that may exist on a packet network: terminals, 

35 Multipoint Control Units ("MCUs"), gatekeepers, and gate- 
ways. Terminals support at least voice communications and 
optionally support multimedia communications, and include 
such components as personal computers and IP phones with 
at least voice capability and optionally multimedia capabil- 

40 ity. MCUs support conferencing for three or more network 
endpoints. Gatekeepers provide network management and 
virtual Private Branch Exchange ("PBX")-type capabilities, 
such as call control services like address translation for 
network endpoints. Gateways support at least voice and 

45 optionally multimedia inter-networking for connecting IP 
packet-based networks with circuit-switched networks, and 
provide translations between different transmission formats, 
communications procedures, and codecs. 

A synchronous VRU may interface with an asynchronous 

50 packet network via a PSTN/packet gateway. A PSTN/packet 
gateway converts TDMA voice signals received, for 
example, over a standard PSTN line, into packetized voice 
signals, and vice versa, and allows the resources in the PSTN 
network to exchange information with resources in the 

55 packet network. Generally, the PSTN/packet gateway also 
performs conversion of analog signals to digital signals (if 
required), or accepts the ^-law encoded digital signals 
directly from the PSTN. The gateway may optionally com- 
press the digitized signals from ^-law (about 64 Kbps) down 

60 to as low as about 5 Kbps before packetizing (and vice 
versa). The packetized voice signals may be multiplexed 
with numerous other signals for transmission over a data 
line. Atypical application of such a PSTN/packet gateway is 
providing an alternative to making a long distance call. 

65 Instead of making a long distance connection where the 
network uses digital TDMA lines at approximately 64 Kbps 
of bandwidth per call, callers may make a local POTS call 
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to a PSTN/packet gateway. The gateway may digitize, if over a switched network (e.g., lower cost long distance), this 
necessary, and optionally compress the incoming signal type of implementation is probably best applicable as an 
down to about 5 or 6 Kbps. The gateway then packetizes the interim solution. For example, there may be some draw- 
signal. These packetized signals may then be multiplexed backs associated with the implementation described above, 
and routed in bulk very cheaply over long distances on a data 5 First, packet networks, not switched networks, appear to be 
grade network. At the other end, another PSTN/packet me dominant type of network for future communications, 
gateway receives and reassembles the packetized signal, and anc j tnus tDC synchronous interface in a VRU may become 
then decompresses the signal, if necessary, and converts it j ess utilized. 

back into a TDMA-multiplexed signal. Resources at the _ , . , . , mTI , . _ 
^ . f t u 1 1 nrnx? „„n Second, even though a synchronous VRU may be con- 
distant gateway then make another local POTS call to 0 * » * . ' TT ... 

. A 6 . 3 . . tU „• t * 10 nected to a packet network via a gateway, the VRU still 

complete the connection between the calling party and the „ F . , . . » . 

receivine party generally requires an internal switch to connect one party to 

Asynchronous VRU connected to a PSTN/packet gate- another for many enhan^ services such as caUing card and 

way may provide the enhanced services described above, one-number services. When the call media stream passes 

and take advantage of the additional capabilities of the through the VRU, the application generally uses two ports to 

packet network. Such a system is one of the systems 15 complete the connection, and the VRU ports stay engaged in 

discussed in co-assigned, co-pending patent application Ser. the call for the duration of the call. Typically, prior art VRUs 

No. 08/719,163, entitled INTERACTIVE INFORMATION switch synchronous data in G.711 format, which is the same 

TRANSACTION PROCESSING SYSTEM WITH UNI- format as used by the switches in the PSTN. Because of this, 

VERSAL TELEPHONY GATEWAY CAPABILITIES, by if data arrives in asynchronous G.711 format, or G.723 

Michael Polcyn, filed Sep. 24, 1996. An example of such a 20 format, the data must be converted to synchronous G.711 ' 

system is shown in FIG. 2. As discussed in application Ser. format so that the VRU can process it. 

No. 08/719,163, the VRU (i.e., Interactive \fcice Response Third, the repeated conversions from one data format to 

Unit ("IVR")) may be an automated voice resource known another data format, such as from G.711 to G.723, or from 

in the art, such as the "One Voice" or "IN* Control" synchronous to asynchronous, may delay or degrade the 

platforms, available from InterVoice, Inc., 17811 Waterview 25 an ^ 3j ^ so use ^ p rocess0 r resources which could be 

Parkway, Dallas, Tex., 75252. Ports on the VRU receive ^d f or omer functions more directly related to the core 

individual communications, and resources in the VRU per- functionality of the VRU. 

form processing to make communications in one format Another difficulty with a synchronous VRU being con- 

(e.g., asynchronous data in the packet network) understand- nected tQ a packel network ^ a gateway ^ that this VRU 

able to communications in other formats (e.g. synchronous 30 fc x chil& cuuany in the position of a gateway, which is a 

data in the POTS network). network "edge" device. These edge devices are generally 

In the example system shown in FIG. 2, synchronous expected to handle data translations and multiple device- 

VRU 200 connects to PSTN 202 via Tl trunk 204, as in FIG. ^ ^ g ^ voice> data moc jcm and fax) access to the packet 

1. In addition, VRU 200 connects to PSTN/packet gateway networ k. However, the digital signal processor ("DSF') 

214 via Tl trunk 212, and gateway 214 is connected powcr required for voice over Internet protocol ("VoIP') 

asynchronously to packet network 216. If telephone 218 is compression, V.90 data modems, or fax modems, for 

physically located in a different area than VRU 200, access example, is relatively high. In a VRU, this processing power 

to VRU 200 via the POTS network may require a long wou ld be better ut^zed performing enhanced services, such 

distance phone call. To reduce the cost of this connection, as voice recognition anc i DTMF detection, which are more 

telephone 218 may access PSTN 220, which in turn provides 40 directly related to the core functionality of the VRU. 

a synchronous connection to gateway 224 via Tl trunk 222. Alternatively, the data translation would be better placed in 

Because data in PSTN 220 is in G.711 format, gateway 224 a device which is intended to be a network edge device, such 

may translate the data into G.723 compressed format mr as a gatewav> allowing the VRU to function with less 

transmission over asynchronous packet network 216, or processing power, and thus be more cost efficient, 

gateway 224 may leave the data in G.711 format and not « ^ ^ ehbanatd ^ ^ ^ 

change the compression format for transmission over packet psw ^ m ^ a Ucable to and |lgcfi|1 irj a 

network 216. Gateway 224 also provides the appropriate cke(4)ased Qetwork . Generally, customers will still want 

headers for routing the packete to gateway 214. Gateway ^ Qf f ^ b eveQ ff 

214 may then decompress the reassembled packets, if ™£ netwQrk of ^ pQTS 

necessary, from G.723 format aaa^ranshte the data into ^ and * cn £ ^ ^ ^ d 

f ° rn ? , traDSmiSS ^ * ™ 200 °™ T1 or a combination thereof, instead of voice only. 

212. As with the system in FIG. 1, each specific connection . 

made by VRU 200 generally requires a port and a 64 Kbps These and other <*J ec,s > features and technical advan- 

channel on Tl trunk 212. If the enhanced service being fges •« generally achieved by a system and method for a 
provided by VRU 200 requires connecting telephone 218 to » P"*et VRU which directly utilizes packet network 

another device external to VRU 200, for example to tele- protocols, such as those of the H.323 standard, to provide 

phone 206 or telephone 232, then internal synchronous enhanced services in a packet network. The VRU may 

switch 238 and another port and 64 Kbps channel are directly connect to the packet network as a network core 

required to complete the connection. In addition, if the device, or connect via another network core device, such as 
connection to the external device is back through gateway «° " H323 gatekeeper. In contrast to a network edge device 

214 and packet network 216, the entire sequence of (e.g., a gateway), a network core device (e.g., a gatekeeper 

compression/decompression, if necessary, and translation °r » f°<"er) generally operates "witlnn the packet network 

must be performed again. arrf is not required to provide data format translation (e.g., 

synchronous to asynchronous) or multiple device-type 

SUMMARY OF THE INVENTION 6S access ( e g ^ f ax modem). Advantageously, the packet 

While a synchronous VRU connected to a gateway may VRU may be built entirely in software running on a network 

take advantage of many of the benefits of a packet network server with a standard packet network connection such as 
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Ethernet or token-ring. The H.323 software protocol may 
contain all of the call placement, progress, and termination 
functions, implemented as out-of-band signaling in a format 
similar to ISDN's Q.931 standard. 

In a preferred embodiment of the present invention, a 
packet VRU may connect two or more parties together via 
the packet network, such as for an 800 calling card service 
or for a teleconferencing service. Analogous to the discus- 
sion above with respect to the synchronous VRU connected 
to the PSTN, it is desirable for the packet VRU to be able to 
connect two or more parties together and still maintain 
control of the call. This includes call administrative 
functions, tracking call context, processing input from users, 
etc. Therefore it is generally useful for a packet VRU to 
maintain control of the call and receive user input, signaling, 
or the audio stream, for example to detect user input 
indication (e.g., DTMF) messages, interpret voice input, or 
sum voices in a conference call. One way to accomplish this 
is for the packet VRU to receive and process the packets sent 
by a source, and then re-transmit the packet information to 
the proper destinations. 

However, there are generally three important sources of 
delay encountered when transmitting data across a packet 
network. First, there is a delay introduced if the data is 
compressed by the source. Generally, the source gateway 
must receive and store enough data in order for it to execute 
the compression algorithm. Depending on the specific algo- 
rithm used, compression can introduce, for example, 30 
msec of delay into the signal. Second, there may be a delay 
introduced by the source converting the data from non- 
packet form into packet form. Generally, the source gateway 
must receive and store a certain amount of data to fill a 
packet, and then generate a header to affix to the packet data. 
This packetization can introduce, for example, 50 msec of 
delay into the media transfer. Third, there may be a delay due 
to the inherent asynchronous nature of a packet network. 
Generally, packets arrive at a destination at varying times, 
and may even include overlapping and out-of-sequence 
packets. For the transferring of data files, this "jitter" gen- 
erally does not introduce any significant problems because 
the data is not time critical. For real-time data, however, 
such as voice, video or multimedia data, a jitter buffer may 
be necessary to reconstruct the packets into a real-time 
message. The jitter buffer can introduce, for example, 100 
msec of delay into the media stream because it must com- 
pensate for the jitter in the arrival of the packets. 

These compression, packetization and jitter delays may 
all be present in any transfer of data from a source to a 
destination in a packet network. If a packet VRU receives 
packetized data from a source and then re-transmits the 
packet ized data to a destination, all three delays may be 
present in each separate media stream (i.e, from the source 
to the VRU, and from the VRU to the destination). Adding 
the second set of delays to the transfer may be unacceptable 
for real-time media communication. In addition, there may 
be excess delay associated with the transportation of the two 
(or more) separate media streams in the network, especially 
if the originating and terminating parties are located close to 
each other and the packet VRU is located far from the 
parties. Generally, this delay may be caused both by the 
increased distance that the signals must travel, and by all the 
extra routers and switches and other circuitry which the 
signals must pass through in the network. Users are very 
sensitive to delay, which can be distracting at the least, and 
may cause parties to start talking over one another if the 
delay becomes too excessive, significantly disrupting the 
conversation. Delay may even cause sufficient user dissat- 
isfaction to push users to seek another service provider. 
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Accordingly, it is highly desirable for the packet VRU to 
reduce or avoid these delays, while at the same time main- 
taining control of the call. In a preferred embodiment of the 
invention the packet VRU may utilize protocols available in 

5 the packet network to redirect a source's media stream from 
the packet VRU to another destination. In this way the media 
stream is sent directly to the destination instead of passing 
through the packet VRU. Alternatively, if the packet VRU 
must perform processing on the message contents, the 

10 packets may be directed to the receiving parties, and in 
addition continue to be sent to the packet VRU. By redi- 
recting the packets directly to the receiving parties, these 
embodiments generally avoid any additional compression, 
packetization and jitter delays that would be introduced by 

15 a second subsequent media stream from the VRU to the 
destination. 

In a preferred embodiment, the packet VRU generally 
redirects only the media streams themselves to be sent 
directly between the parties. The packet VRU may still 

20 retain call control over the media streams by maintaining the 
signaling and user input components of the call. For 
example, the RTP/RTCP media streams may be redirected to 
be sent directly between the gateways, but the H.245 and 
Q.931 call structures between the gateways and the VRU 

25 may be kept intact. 

In H.323 VoIP architecture, the DTMF or other user 
signaling may be taken out-of-band from the RTP streams 
using H.245 Userlnputlndication messages, as described in 
more detail in section 7.12.6 of the H.245 specification. This 

30 feature was specified in the H.323v2 specification because 
some voice compression schemes destroy in-band DTMF 
information. This feature was intended to allow out-of-band 
DTMF information to be sent to the same endpoint as the 
in-band voice information, but this feature may also be 

35 exploited to route the user input to a different endpoint than 
the RTP media stream. H.245 section 7.12.6 User Input also 
describes a method to provide DTMF duration information 
in the Userlnputlndication messages using Signal and Sig- 
nalUpdate parameters. This feature may be used to transfer 

40 tone duration information out-of-band from the RTP 
streams. Tone duration is useful in many applications, such 
as calling card call re-origination. 

Thus in a further preferred embodiment of the present 
invention, a gateway or browser may convert user input 

45 indication signals (e.g., DTMF signals from a telephone, or 
keyboard input from an IP phone) received from a party 
connected via the gateway or browser into user input indi- 
cation messages in an out-of-band channel in the H323 
protocol to be read by the packet VRU, separate from the 

50 redirected media streams. This may be especially useful for 
higher compression schemes (e.g., G.723) which cannot 
properly compress and decompress user input indication 
signals in-band with the voice signal. By using user input 
indication messages, the packet VRU advantageously does 

55 not need to receive the media streams if the sole reason is to 
detect user input indication signals, and this approach also 
circumvents the digital signal processing associated with 
in-band user input indication detection. Thus the packet 
VRU may redirect the media streams to travel directly 

60 between the parties without passing through the packet 
VRU, and still maintain call control, including receiving 
user input indication messages from the users. Alternatively, 
if the receiving party also needs to receive user input 
indication signals, for example if the receiving party is a 

65 synchronous VRU monitoring user input indication signals, 
then either the originating gateway or the packet VRU can 
send the user input indication messages to the destination 
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gateway, which may then convert the messages back into call comprises a second call control structure and a second 

actual user input indication signals added into the voice media stream, means for signaling the first device to redirect 

signal, the first media stream to the second device, and means for 

In an alternative embodiment, the packet VRU may solely signaling the second device to redirect the second media 

utilize a voice-recognition user interface and therefore not 5 stream to the first device, wherein the first and second call 

require user input indication signals at all. Alternatively, if control structures are not redirected away from the system, 

the user input indication signals are implemented in-band In accordance with still another preferred embodiment of 

with the data channel, a user input indication detector in the the present invention, a system for redirecting media in an 

packet VRU may be implemented, and for further function- asynchronous packet network comprises an asynchronous 

ality a user input indication generator may also be imple- 10 interface to the packet network, a call control server, 

mented in the packet VRU. For these latter two wherein the call control server sets up call control structures 

embodiments, in addition to the media streams being trans- to communicate with devices in the packet network via the 

ferred directly between the parties, the packet VRU would asynchronous interface for controlling media streams from 

also need to receive copies of the media streams to process and to the devices, a voice media server communicating with 

the data contained in them. One example of a standard for 15 the call control server, wherein the call control server uses 

user input indication data transfer and reproduction is the the call control structures to establish media streams 

"Voice over IP Interoperability Implementation Agreement," between the devices and the voice media server via the 

developed by the International Multimedia Teleconferenc- asynchronous interface, and an application server commu- 

ing Consortium ("IMTC"), located in San Ramon, Calif, and nicating with the call control server and the voice media 

with a WWW site of "http://www.imtc.org." The 20 server, wherein the application server instructs the call 

specification, which supports two party voice and voice- control server to redirect the media streams to be transmitted 

band calls over IP networks, is based on H.323 standards and directly between the devices without passing through the 

includes other telephony-specific requirements and IP spe- system, and wherein the call control structures are retained 

cific needs such as directory services and dynamic IP between the devices and the system, 

address resolution mechanisms. 25 One advantage of a preferred embodiment of the present 

In accordance with a preferred embodiment of the present invention is that a packet VRU may generally provide the 

invention, a method for redirecting media in an asynchro- existing enhanced services of a synchronous VRU, but in a 

nous packet network by a system asynchronously connected packet network environment. Another advantage of a pre- 

to the packet network comprises establishing a first call ferred embodiment of the present invention is that a packet 

between a first device and the system via the packet network, 30 VRU may provide enhanced services for multimedia com- 

wherein the first call comprises a first call control structure munications in addition to voice-only communications, 

and a first media stream, and signaling the first device to Because of the added multimedia functionality, a packet 

redirect the first media stream to a second device, wherein VRU may also be described as a packet Multimedia 

the first call control structure is retained between the first Response Unit ("MRU"), or a packet Interactive Multimedia 

device and the system. In a further aspect of this preferred 35 Response ("IMR") Unit. All such systems may also be 

embodiment, the method further comprises establishing a referred to as a packet Enhanced Service Provider ("ESP"), 

second call between the system and the second device via Of course, with the added multimedia functionality, new 

the packet network, wherein the second call comprises a enhanced services, such as video conferencing, shared 

second call control structure and a second media stream, and whiteboarding and text chatting, which were not imple- 

signaling the second device to redirect the second media 40 mented in voice-only communications, will become 

stream to the first device, wherein the second call control desirable, and all such enhanced services are intended to be 

structure is retained between the system and the second within the scope of the present invention, 

device. A further advantage of a preferred embodiment of the 

In accordance with another preferred embodiment of the present invention is that repeated conversions from one data 

present invention, a computer program product having a 45 format to another data format are avoided because the media 

computer readable medium with computer program logic is sent directly from source to destination, and not through 

recorded thereon for use in a system asynchronously con- the packet VRU. In addition, because the packet VRU is 

nected to a packet network for redirecting media in the implemented as a core device within the packet network 

asynchronous packet network, comprises code for establish- instead of as an edge device, the packet VRU does not need 

ing a first call with a first device via the packet network, 50 to provide multiple device-type access such as for modems 

wherein the first call comprises a first call control structure and fax machines. Instead, gateways generally direct only 

and a first media stream, code for establishing a second call the voice calls to the packet VRU and direct fax and modem 

with a second device via the packet network, wherein the calls elsewhere. Also, the packet VRU may not need to 

second call comprises a second call control structure and a provide data format conversion between the packet network 

second media stream, code for signaling the first device to 55 and another type of network, such as a switched network, 

redirect the first media stream to the second device, and code although connecting a combined packet/synchronous VRU 

for signaling the second device to redirect the second media to both types of networks may still be desirable for some 

stream to the first device, wherein the first and second call applications. 

control structures are not redirected away from the system. A further advantage of a preferred embodiment of the 

In accordance with yet another preferred embodiment of 60 present invention is that a packet network interface generally 

the present invention, a system for redirecting media in an does not require multiple physical ports and an internal 

asynchronous packet network comprises an asynchronous switch for connecting more than one party together for 

interface to the packet network, means for establishing a first enhanced services such as calling card and one-number 

call with a first device via the packet network, wherein the services. Instead, any switching/routing is handled in the 

first call comprises a first call control structure and a first 65 packet network itself. A single packet network interface may 

media stream, means for establishing a second call with a handle all traffic with the packet VRU. For example, a single 

second device via the packet network, wherein the second 100 Mbit Ethernet interface may carry over 10,000 5 Kbit 
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G.723 compressed voice channels plus overhead. FIG. 6 is a flow diagram illustrating a message protocol 

Alternatively, more than one packet network interface may for tearing down redirected media using communication 

be implemented. In addition, multiple parties may be con- mode command procedures; 

nected by redirecting the media streams to travel directly FIG. 7 is a flow diagram illustrating a message protocol 

between the parties, without passing through the VRU. Thus 5 for redirecting media using user input indication messages; 

the packet VRU may avoid the delays associated with an and 

internal jitter buffer, internal processing of the packets, and pj G g is a fl ow diagram illustrating a message protocol 

separate media streams from the VRU to each party. f or tearing down redirected media using user input indica- 

A further advantage of a preferred embodiment of the tion messages, 

present invention is that a packet VRU may redirect the 1° 

media streams and still retain control of the call by keeping DETAILED DESCRIPTION 
the call states between the parties and the VRU intact. 3, is a block diagram of a preferred embodiment of 
Redirecting the media streams may free up valuable me present invention in which packet VRU 600 is connected 
resources in the packet VRU, such as voice recognition to packet network 602 via asynchronous Ethernet interface 
resources, so that they can be used to handle other calls. In 15 504. p ac ket VRU 600 is capable of using H.323 protocols or 
addition, the packet VRU may still receive user input omer packet network protocols to communicate with other 
indication messages. This embodiment has a further advan- devices in packet network 602. In this embodiment, packet 
tage over a synchronous VRU in that it can perform a VRU 600 communicates directly with gateway 606, via the 
function similar to RLT in the PSTN, discussed above, but packet network side, to allow connection of multiple devices 
still monitor for user input indication signals and still keep 20 mat are external to packet VRU 600. By communicating 
track of the call context. Thus the packet VRU, and not the witti gateway 606, packet VRU 600 can effectively perform 
network, would monitor for user input indication signals. mose enhanced services which require switching (e.g., 800 
For example, if the packet VRU redirects a calling card calling card service and one number service) in the synchro- 
caller's call from a third party to the VRU in response to a nous VRUs illustrated in FIGS. 1 and 2, but without requir- 
user input indication message, the calling card caller would 25 jug an internal hardware switching mechanism, 
not have to re-enter Card Number and PIN information to Packet y^j 60Q deludes data processor 620 and memory 
make a second calling card call. 622. Data processor 620 may be a processor board contain- 
Yet another advantage of a preferred embodiment of the fog one or more general purpose processors, DSPs, or 
present invention is that generally only the amount of ^ custom processors. Memory 622 may be any type of typical 
bandwidth needed is used in the packet network interface storage device used in computers such as a magnetic or 
(and throughout the packet network), instead of the 64 Kbps optical disks, non-volatile or volatile RAM or magnetic tape, 
channels generally required for each connection in a Tj a ta processor 620 provides control and interactive corn- 
switched network. muni cation with users and handles user requests, while 
The foregoing has outlined rather broadly the features and 35 memory 622 provides storage for outgoing messages or 
technical advantages of the present invention in order that message components and for recording user input, 
the detailed description of the invention that follows may be Similar to the network discussed above with respect to 
better understood. Additional features and advantages of the FIG. 2, gateway 606 is connected to packet network 602 via 
invention will be described hereinafter which form the a packet-based interface. Gateway 606 provides a network 
subject of the claims of the invention. It should be appre- ^ bridge between packet network 602 and PSTN 608, and thus 
ciated by those skilled in the art that the conception and to the devices connected to PSTN 608, such as telephone 
specific embodiment disclosed may be readily utilized as a 618, data modem 610 and fax machine 612. Other devices 
basis for modifying or designing other structures for carry- which may connect to packet network 602 include multi- 
ing out the same purposes of the present invention. It should media personal computer ("PC") 614 and gatekeeper 616, 
also be realized by those skilled in the art that such equiva- 4S both of which are capable of using H.323 protocols to 
lent constructions do not depart from the spirit and scope of communicate with other devices in packet network 602. 
the invention as set forth in the appended claims. [ Q orc j er for telephone 618 to connect to VRU 600, 

telephone 618 must first connect to originating gateway 606 

BRIEF DESCRIPTION OF THE DRAWING via psTN 608) geQerally a G .711 data format. Gate- 

For a more complete understanding of the present SO way 606 may optionally transcode the G.711 format into a 

invention, and the advantages thereof, reference is now hig^r compression/lower data rate format, such as G.723 

made to the following descriptions taken in conjunction with format. Gateway 606 then packetizes the data and attaches 

the accompanying drawing, in which: ^ appropriate headers to the packets for O-ansmission to 

. . . , , , - . . . packet VRU 600 across packet network 602. Because packet 

FIG. 1 is a block diagram of a pnor art synchronous VRU ^ m fa P ^ ^ ^ a 

connected to a PMN, core dcy{c ^ packet ^ 600 generaUy does not nee d to 

FIG. 2 is a block diagram of a synchronous VRU indi- prov i de multiple device-type (e.g., voice, fax and data 

reedy connected to a packet network via a gateway; modem) access to the packet network. These functions are 

FIG. 3 is a block diagram of a packet VRU implemented performed by gateway 606 as a network edge device in 

on a packet network in which two users are connected to 60 linking PSTN 608 to packet network 602; gateway 606 

each other from gateway to gateway in a connection con- generally routes only voice calls to packet VRU 600. 

trolled by the VRU; An H323 call using Q.931 signaling and H.245 call 

FIGS. 4a-4d are a series of block diagrams illustrating a control is set up between gateway 606 and packet VRU 600 

sequence for redirecting media within a packet network; via packet network 602. Packet VRU may then set up an 

FIG. 5 is a flow diagram illustrating a message protocol 65 RTP/RTCP media stream between packet VRU 600 and 
for redirecting media using communication mode command gateway 606. Generally only media data is transmitted over 

procedures; the media stream, not call control or user input indication 
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signals. To connect telephone 618 to another party, such as 
telephone 630, packet VRU 600 sends control signals to 
gateway 606 to redirect the media stream to another device 
linked to packet network 602, such as destination gateway 
626. This preferred embodiment is somewhat similar to RLT 
in a switched network, but with the important difference that 
packet VRU 600 can still maintain control of the call 
because packet VRU 600 does not redirect the call control 
signals. Advantageously, the extra set of delays associated 
with the packets first being received and processed by packet 
VRU 600 and then transmitted to gateway 626 are generally 
eliminated. In addition, the processing requirements for 
packet VRU 600 are generally reduced because all routing 
and data handling can be performed by gateway 606. If 
packet VRU 600 does not need to process the content of the 
data stream, it can request that gateway 606 only send the 
packets across packet network 602 to telephone 630 via 
gateway 626. Alternatively, packet VRU 600 may request 
that gateway 606 replicate the data packets and send them to 
packet VRU 600 for processing, in addition to forwarding 
the data on to telephone 630. Call control and a return media 
stream from gateway 626 to gateway 606 may be set up in 
a manner similar to that described above for gateway 606. 

FIGS. 4a-4d illustrate a sequence for redirecting media 
on a packet network in accordance with another preferred 
embodiment of the present invention, FIGS. 4a-4d illustrate 
how to connect a caller to a called party using an 800 calling 
card enhanced service as an example application. Of course, 
the inventive concepts are applicable to any enhanced ser- 
vice in which a packet VRU connects a party to one or more 
other parties via a packet network. In general, the calling 
party may be a person, such as a customer, or may be a 
robotic resource, such as another packet VRU. The other 
party may be another person, such as another customer or an 
agent, or may be a robotic resource, such as an automated 
agent, or another VRU. Some of the details shown in FIG. 
3, such as fax machines and modems, are omitted from 
FIGS. 4a-4d for clarity, but the discussions with respect to 
FIG. 3 are still applicable to the embodiment illustrated in 
FIGS. 4a-4d. 

With reference to FIG. 4a, there is shown VRU 800 
asynchronously connected to IP network 806, for example 
via an Ethernet connection. VRU 800 includes call control 
server ("CCS") 802, voice media servers) ("VMS") 804, 
and application server 803. An NSP-5000, available from 
Inter Voice, Inc., 17811 Waterview Parkway, Dallas, Tex., 
75252, with Calling Card and VoIP capability may be used 
to implement VRU 800. Domain gatekeeper 808 is also 
connected to IP network 806, and maintains a directory of IP 
addresses for the various devices in the network. Also 
present on the network are gateways with \bIP capability, 
such as originating gateway 810 and terminating gateway 
812 (also referred to herein as destination gateway). 

In this preferred embodiment the VRU provides an 800 
calling card service. In a standard 800 calling card service, 
a caller dials the 800 service access number for the VRU. 
The VRU carries on an interactive dialog with the caller in 
order to obtain the caller's Card Number, PIN and the PSTN 
phone number for a desired party with whom the caller 
wishes to communicate. The VRU verifies the PIN and 
attempts to connect the caller to the desired party. The 800 
calling card service may be a prepaid or postpaid service. In 
either case, the VRU generally needs to monitor the duration 
of the phone call in order to charge the caller the correct 
amount of money for the phone call. If a preset or prede- 
termined limit is in effect, (i.e., either the amount of money 
on a prepaid calling card, or a ceiling on the amount of credit 
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allowed for a postpaid card), then the VRU also needs to 
monitor and have control over the phone call so that the call 
can be terminated if the limit is reached or exceeded. 
In FIG. 4a } a caller using POTS telephone 814 dials the 

5 800 service access number. The PSTN network routes the 
call 816 to originating gateway 810. Preferably, originating 
gateway is physically located close to the caller, so that 
minimal cost is incurred in the PSTN network. The service 
provider for the 800 calling service may have gateways 

10 located throughout a country, for example in the major cities 
in the United States. In a preferred embodiment, the original 
800 call is routed to the closest gateway in the PSTN. 
Alternatively, the original 800 call is always routed to a 
specific gateway, irrespective of the location of the caller. 

15 Originating gateway 810 receives the call from the PSTN, 
and queries 818 domain gatekeeper 808 via IP network 806 
for the PSTN-number-to-IP address translation, which is 
sent back 818 to gateway 810 by gatekeeper 808. 
Originating gateway 810 then establishes H.323 call 820 

20 to CCS 802 in VRU 800. Q.931 call signaling identifies the 
source and destination and establishes a virtual signal con- 
nection between gateway 810 and VRU 800. The signaling 
connection is established when the H.323 Stack signals that 
the call is in the connected state. Then the H.245 call control 

25 process exchanges capabilities between gateway 810 and 
VRU 800, and is complete when gateway 810 and VRU 800 
have established inbound and outbound logical channels 
between each other. Once the inbound and outbound logical 
channels (User Datagram Protocol ("UDF') addresses) are 

30 known, an RTP/RTCP session can be established for trans- 
ferring media streams between gateway 810 and VRU 800. 

CCS 802 determines caller ID and called number infor- 
mation from the H.245-Q.931 data. CCS 802 uses the caller 

3S ID and called number information to determine the type of 
service (application) to be applied to the incoming call, in 
this case 800 calling card service, by application server 803, 
which initiates the appropriate application. CCS 802 also 
selects the port in VMS 804 to be used to handle the call, and 

^ sends the card application context data 822 to VMS 804. 
CCS 802 directs originating gateway 810 to send its RTP 
stream to a media port on VMS 804. Similarly, VMS 804 is 
directed by CCS 802 to send its RTP stream to originating 
gateway 810, thus establishing a full duplex audio connec- 

4S tion 824 between originating gateway 810 and VMS 804. As 
discussed hereinabove, gateway 810 is an edge device, and 
provides for translation between synchronous PSTN and 
asynchronous IP network 806. 
Application server 803 may then command VMS 804 to 

50 execute an interactive voice script with the caller to provide 
voice greetings and menus. The script obtains the caller's 
Card Number, PIN and the PSTN phone number that the 
caller wishes to reach, in this case the phone number for 
POTS phone 832. POTS phone 832 is connected to IP 

55 network 806 via the PSTN and gateway 812. Application 
server 803 validates the Card Number and PIN in its 
customer card database. 

Turning now to FIG. 4b, application server 803 directs 
CCS 802 to place a separate, secondary call to POTS 

60 telephone 832, which has the PSTN number specified by the 
caller. To accomplish this, CCS 802 first queries 826 gate- 
keeper 808 to find the IP address of the appropriate gateway 
to reach the called PSTN number, in this case terminating 
gateway 812. Gatekeeper 808 returns 826 the IP address of 

65 gateway 812 to CCS 802. CCS 802 then places a second 
H.323 call 828 to terminating gateway 812 by using the IP 
address provided by gatekeeper 808. When terminating 
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gateway 812 responds to H.323 call 828, CCS 802 directs 
terminating gateway 812 to send its RTP stream to an IP 
address on VMS 804. Similarly, VMS 804 is directed to send 
its KTP stream to terminating gateway 812, thus establishing 
a second fall duplex audio connection 830 (two opposite 
direction RTP sessions) between terminating gateway 812 
and VMS 804. 

Finally, to reach the desired party, CCS 802 instructs 
terminating gateway 812 to extend H.323 call 828 into the 
PSTN using the POTS number provided by the caller. 
Terminating gateway 812 complies by placing PSTN call 
834 to the called party on POTS phone 832. Application 
server 803 monitors the call progress, and when answer 
occurs, application server 803 instructs VMS 804 to execute 
an interactive voice script with the called party. The script 
may provide voice greetings with screening and identifica- 
tion of the called party. At this point there are two separate 
connections established via IP network 806, from POTS 
phone 814 to VRU 800, and from VRU 800 to POTS phone 
832. 

Turning now to FIG. 4c, there is illustrated a preferred 
embodiment of the invention, in which media sent to VRU 
800 is redirected to travel directly between the originating 
gateway 810 and terminating gateway 812, thus bypassing 
VRU 800. Once the called party is validated, application 
server 803 instructs CCS 802 to redirect the media streams. 
CCS 802 requests that originating gateway 810 and termi- 
nating gateway 812 send their respective RTP streams 
directly to each other, instead of to VMS 804. CCS 802 
accomplishes this by tearing down RTP session 824 between 
originating gateway 810 and VMS 804, and by tearing down 
RTP session 830 between terminating gateway 812 and 
VMS 804. Only RTP sessions 824 and 830 are torn down; 
H.323 call 820 between originating gateway 810 and VMS 
804, and H323 call 828 between terminating gateway 812 
and VMS 804, are left connected. 

To establish communications directly between the 
gateways, CCS 802 requests that originating gateway 810 
redirects its RTP stream 836 to terminating gateway's 812 
media port. Likewise, CCS 802 requests that terminating 
gateway 812 redirect its RTP stream 838 to originating 
gateway's 810 media port. Again, the H.323 call states are 
not modified, only the RTP streams are moved. Thus CCS 
802 may still monitor out-of-band user input indication 
signaling on the originating leg of H.323 call 820 from the 
calling party via originatin g gateway"8I 07VRU 800 may 
still monitor and control the communication between the 
calling and called parties via H.323 calls 820 and 828, but 
data sent between the calling and called parties travels via 
RTP streams 836 and 838 and no longer needs to pass 
through VRU 800. Alternatively, for some enhanced 
services, VRU 800 may still need to monitor the contents of 
the call between the calling and called parties. In that case, 
VRU 800 may not tear down the original RTP streams and 
instead simply establish the new RTP streams, which are 
copies of the original RTP streams. Once the call is 
terminated, either by one of the parties or by the VRU, 
application server 803 instructs CCS 802 to tear down RTP 
streams 836 and 838, and H.323 calls 820 and 830. VRU 800 
may also complete any administrative tasks, such as statis- 
tical recording or billing calculation and recording. 

Alternatively, a similar approach may be used to establish 
connections between more than two parties external to VRU 
800, for example to provide a conferencing application. 
VRU 800 sets up multiple H.323 calls and associated RTP 
media streams to each party participating in the conference, 
and then redirects the media streams to be transmitted from 
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each party to every other party. The primary difference from 
the method discussed above with respect to FIGS. 4a-4c is 
that the media stream from each party is redirected to be 
transmitted to more than one destination. In one alternative 

5 embodiment, the participants or the equipment in their paths, 
such as their respective gateways, have the ability to perform 
the summation of the incoming signals themselves, and 
VRU 800 is not required to receive the media streams. In 
another alternative embodiment, the participants do not 

1Q perform the summation of the incoming media streams, so 
VRU 800 receives each of the media streams, performs the 
summation of the signals, and sends the media streams out 
to each of the participants. In either case, and as discussed 
above, VRU 800 retains control of the call by leaving the 

15 H.323 calls intact. Also as discussed above, VRU 800 may 
still monitor for user input indication messages transmitted 
via the H.323 calls. 

Turning to FIG. 4d, in another preferred embodiment, a 
caller may wish to place another phone call after completing 

20 a prior phone call without repeating the entire procedure of 
dialing the 800 number and entering in the Card Number and 
PIN. The only new information required from the caller to 
perform the re-origination function is the new destination 
telephone number. To make a new call, caller holds down the 

25 pound key on POTS telephone 814 for longer than 2 
seconds. Originating gateway 810 relays this signal to CCS 
802 via out-of-band user input indication signaling on H323 
call 820. Upon receiving indication that the caller desires to 
make another telephone call, application server 803 instructs 

30 CCS 802 to tear down H.323 call 828 to terminating 
gateway 812 and RTP streams 836 and 838. Originating 
gateway 810 may use the key-on key-off Userlnputlndica- 
tion messages for user input indication carriage in accor- 
dance with H.245v3. Only originating H.323 call 820 is left 

35 active. 

To make the new phone call, application server 803 
instructs CCS 802 to re-establish a full-duplex RTP session 
with a media port on VMS 804, as discussed with respect to 
RTP stream 824 in FIG. 4a. Also similar to the discussion 

4Q with respect to FIG. 4a } application server instructs VMS 
804 to execute an interactive voice script with the caller. The 
script provides voice greetings and menus. Since the service 
application has already validated the caller, the script only 
needs to obtain the next PSTN phone number that the caller 

45 wishes to reach. Once the new phone number is obtained, the 
process is repeated again as discussed with respect to FIGS. 
4b-4c. If the caller hangs up, all H.323 calls are torn down 
and caller context is discarded. 
Generally, there are many ways to redirect a media stream 

50 in a packet network without affecting call control, and all 
such systems and methods are intended to be within the 
scope of the present invention. Media redirection may be 
implemented using custom functionality in the packet 
network, or it may be implemented in compliance with a 

55 defined methodology, such as by using functionality 
described in the H.323 specification. 

Some of these systems and methods have been tested in 
the laboratory for viability. The laboratory setup comprised 
a VRU system including an InterVoice ISA VCD card, a 

60 Natural MicroSystems ("NMS") Ag4000 card, an NMS 
Tx3210 card, NMS Fusion 3.0 software, and application 
software implementing the media redirect functions 
described herein. The laboratory setup also comprised two 
gateway systems, each including an NMS Ag8 card, an 

65 NMS T1/RT2 card, an NMS Tx2000 card, NMS Fusion 2.0 
software, and a sample application software implementing 
the gateway functions described herein. The NMS products 
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are available from Natural MicroSystems, 100 Crossing This sequence is repeated for Call B with gateway 903 in 

Boulevard, Framingham, Mass., 01702-5406. The Fusion order to redirect Call B's media stream. VRU 901 sends 

H.323 Stack Programmer's Guide and Reference, NMS P/N Communication Mode Command 913 to instruct gateway 

6448-12, incorporated herein by reference, provides more 903 about a new multicasting address for Call B. In 

detailed information about the NMS Fusion software. 5 response, gateway 903 closes the current (previously 

H.323 section 8.3.5, entitled "Communication Mode opened) outgoing logical channel for Call B with VRU 901, 

Command Procedures" describes functionality that may be anc j issues the CloseLogicalChannel message 914 to VRU 

used to implement the present invention: 901. VRU 901 acknowledges the closing of the current 

The CommunicationModeCommand can be used to outgoing channel for Call B by sending the CloseLogical- 

instruct endpoints in a conference (or a point-to-point 10 ChannelAck message 915 to gateway 903. Then gateway 

call) to change modes by indicating a new mode for a 9Q3 operis a new outgoing channel for Call B and issues 

mediaChannel that is already in use. It can also be used OpenLogicalChannel message 916 to VRU 901. VRU 901 

to tell an endpoint to transmit the media stream to a new acknowledges the opening of the new logical channel for 

address by indicating the mode currently in use, but Call fi ^ gateway 903 and sends OpenLogicalChan- 

with new mediaChannel. Similarly, an endpoint that M QelAck m e 917 which contains call A's IP and RTP 

receives a CommunicationModeCommand indicating ^ lhus ^ iTCCt i ng Ca Jl B's media 

the mooe trendy in ^ glteway 902. Upon completion of the media 

close the appropriate channel and the attempt to reopen 6 • 7 K. r 01fi . fka 

using the OpenLogicalChannel- redirection, a media redirect done message 918 is sent to the 
OpenLogicalChannelAck sequence, where the Open- application indicating that the media redirect is complete 
LogicalChannelAck contains the address to which the 20 Once the call is completed, or for another reason, the 
endpoint will send the media. application may issue request 924 that the redirected media 
In accordance with a preferred embodiment of the present streams be torn down. After tearing down the RTP streams, 
invention, FIG. 5 illustrates a message protocol 900 for VRU 921 may either command gateways 922 and 923 to tear 
redirecting media using the Communication Mode Com- down the call controls, or VRU 921 may command gateways 
mand Procedures. This approach generally uses the com- 25 922 and 923 to set up new RTP sessions with VRU 921, 
munication mode of multicasting and the decentralized similar to the structure that existed before the media redi- 
conference characteristics described in the H.323 standard. rection. To illustrate the latter option, and with reference to 
In order to implement media redirection in this manner, the message protocol 920 in FIG. 6, assume that the media 
participating gateways generally should support the Confer- redirection illustrated in FIG. 5 has already taken place, and 
ence mode described in section 8.3.5 of the H.323 specifi- 30 that the media streams are set up directly between gateway 
cation. The VRU generally should be identified as a Multi- 922 and gateway 923 for Calls A and B. 
point Controller ("MC) entity under the H.323 standard. In VRU 921 first executes the steps to tear down Call A's 
addition, to initiate the Conference mode, a VRU generally redirected RTP media stream. VRU 921 sends Communi- 
should be the master terminal endpoint on the call, so the cation Mode Command 925 to instruct gateway 922 about a 
gateway routing calls to the VRU generally should be 35 new multicasting address for Call A. In response, gateway 
configured to allow slave status. Preferably, the conferences 922 closes the current (previously directed to gateway 923) 
generally should be of the same data type (e.g., G.711) and outgoing logical channel for Call A, and issues the Close- 
have the same data rate (e.g., 64 Kbytes/sec). Alternatively, LogicalChannel message 926 to VRU 921. VRU 921 
the media streams may have different data types or data acknowledges the closing of the current outgoing channel 
rates, as long as the receiving gateway is capable of decod- 40 for Call Aby sending the CloseLogicalChannelAck message 
ing the data transmitted to it. 927 to gateway 922. Then gateway 922 opens a new 
Assume that there are two separate calls, A & B, already outgoing channel for Call A and issues OpenLogicalChannel 
in the connected state between a first gateway 902 and VRU message 928 to VRU 921. VRU 921 acknowledges the 
901, and between VRU 901 and a second gateway 903, as opening of the new logical channel for Call A with gateway 
discussed hereinabove. The application issues request 904 to 45 922 and sends OpenLogicalChannelAck message 929, 
connect A and B in media redirect mode. VRU 901, func- which contains the IP and RTP address of VRU 921, to 
tioning as an MC, sends Multipoint Conference Indication gateway 922, thus redirecting Call A's media stream to VRU 
906 to gateway 902 for call A, putting A into conference 921. VRU 921 sends End Multipoint Conference message 
mode. Likewise, VRU 901 sends Multipoint Conference 930 to gateway 922 to end the conference mode with Call A 
Indication 907 to gateway 903 for call B, putting B into 50 reverting to a connected state with VRU 921. 
conference mode. This sequence is repeated for Call B with gateway 923 in 
VRU 901 then executes the steps to redirect A's RTP order to tear down CaU B's redirected RTP media stream, 
media stream. VRU 901 sends Communication Mode Com- VRU 921 sends Communication Mode Command 931 to 
mand 908 to instruct gateway 902 about a new multicasting instruct gateway 923 about a new multicasting address for 
address for Call A. In response, gateway 902 closes the 55 Call B. In response, gateway 923 closes the current 
current (previously opened) outgoing logical channel for (previously directed to gateway 922) outgoing logical chan- 
Call A with VRU 901, and issues the CloseLogicalChannel nel for Call B, and issues the CloseLogicalChannel message 
message 909 to VRU 901. VRU 901 acknowledges the 932 to VRU 921. VRU 921 acknowledges the closing of the 
closing of the current outgoing channel for Call Aby sending current outgoing channel for Call B by sending the Close- 
the CloseLogicalChannelAck message 910 to gateway 902. 60 LogicalChannelAck message 933 to gateway 923. Then 
Then gateway 902 opens a new outgoing channel for Call A gateway 923 opens a new outgoing channel for Call B and 
and issues OpenLogicalChannel message 911 to VRU 901. issues OpenLogicalChannel message 934 to VRU 921. VRU 
VRU 901 acknowledges the opening of the new logical 921 acknowledges the opening of the new logical channel 
channel for Call A with gateway 902 and sends OpenLogj- for Call B with gateway 923 and sends OpenLogicalChan- 
calChannelAck message 912, which contains call B's IP and 65 nelAck message 935, which contains the IP and RTP address 
RTP address, to gateway 902, thus redirecting Call A's of VRU 921, to gateway 923, thus redirecting Call B's 
media stream to gateway 903. media stream to VRU 921. VRU 921 sends End Multipoint 
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Conference message 936 to gateway 923 to end the confer- Message 954 to gateway 948 to command gateway 948 to 

ence mode with Call B reverting to a connected state with drop the media stream between gateway 948 and the VRU. 

VRU 921. Upon completion of the media redirection tear \bIP driver 944 then sends NEW_RTP A-to-B Message 956 

down, a media redirect disconnect done message 937 is sent to gateway 946 to establish the new media stream from 

to the application indicating that the media redirect tear 5 gateway 946 to gateway 948. Similarly, VoIP driver 944 then 

down is complete. sends NEW_RTP B-to-A Message 958 to gateway 948 to 

In these preferred embodiments, all message protocols establish the new media stream from gateway 948 to gate- 
generally are already available in the H. 323 specification, so way 946 Finally> VoIp driver 944 xnd& media redirect 
custom modifications to the gateways are not required, complete message 959 back to VRU application 942 to 
although the gateways generally should be compliant with 1Q completio[1 of the media redirection. As previously 
the relevant sections in the H.323 specification. Upon discU ssed, only me media slrea m S are redirected, and the 
completion of the call, the redirected media streams may be H .245-G.931 call control structures between the VRU and 
torn down in accordance with the H.323 specification. each gateway are left mtact 

Other embodiments may require some custom function- Qnce the ^ ^ or for another reason> me yRU 

aUtytobeimplementedinthegatewaysforredirectionofthe 1S may mmmujd thc gateways to tear down the redirected 

media streams. In accordance with another preferred media strcams Aftcr mc mcdia streams are torn down> the 

embodiment of the present invention, FIG. 7 illustrates a ^ may cithcf commaQd me gateway s to tear down the 

message protocol for redirecting media using Userlnputln- caU or the yRU may command the gateways to set 

dication messages, and FIG. 8 illustrates an associated up Qew RTp sessions ^ lhe similar to the structur e 

message protocol for tearing down the redirected media 2Q ^ existed before lhe media redirection. To illustrate the 

streams using Userlnputlndication messages. To implement laUer ^ and ^ reference t0 meS sage protocol 960 in 

this embodiment, the gateways generally must be pro- F IG. 8, assume that the media redirection illustrated in FIG. 

grammed to respond to special Userlnputlndication mes- 6 has alread taken placCj ^ that the media streams are set 

sages from the VRU. Because the RTP protocol generally is directl bctw&en gateway 966 and g ate way 968. VRU 

carried over the UDP, and is not associated with the H.245 M application 962 initiates media redirection tear down by 

call context, and because the gateway software does not use ^ media redirect tcar down command 970 to VoIP 

the IP address of the call for the RTP media stream, the drivcr 964 m&ide thc ^ Vo[p drivcr 964 tfaen handlcs the 

system can specify different IP addresses and UDP ports to detai i ed pro tocol of sending Media Redirect Messages to the 

separate the RTP streams from the call control. The VRU gateways t0 accomplish the media redirection tear down, 

may instruct the gateways to keep the dynamic UDP ports 3Q FifSt VoIp drivef 964 sends DRO p_RTP A-to-B Message 

valid by using Userlnputlndication messages. In addition, 9n lQ gateway m (Q gateway 966 t0 ^ the 

the VRU may send a Userlnputlndication message to bring media stfeam from gateway 966 to gat eway 968. Similarly, 

back the redirected media streams to have the RTP session VoIp driver 964 sends DRO p_RTP B-to-A Message 974 to 

established as before the media redirection. gateway 968 to command gateway 968 to drop the media 

In this embodiment, the message protocol comprises the 35 stream from gateway 968 to gat eway 966. VoIP driver 964 

following: mea sends NEW_RTP A-to-VRU Message 976 to gateway 

<Media Redirect Attention> <Media Redirect Command> 966 tQ rce st a blish the media stream from gateway 966 to the 

<,> <DstIpAddress> <,><DstRtpUdpAddress> <,> VRU. similarly, VoIP driver 964 then sends NEW „RTP 

<DstRtcpUdpAddress> <,> <SrcIpAddress> B-to-VRU Message 978 to gateway 968 to reestablish the 

<,><SrcRtpUdpAddress> <,> <SrcRtcpUdpAddress> ^ media slream from ga te Wa y 968 to the VRU. Finally, VoIP 

<,> <RtpSessionMode> driver 964 media re direct complete message 980 back 

All values are in the ASCII Hex representations. The to VRU application 962 to indicate completion of the media 

Media Redirect Attention Command is generally referred to redirection tear down. As previously discussed, only the 

as a "bang," and is defined as media streams are reestablished between the VRU and the 

<Media Redirect Attentions"!" 4S ga teways, and the H.245-G.931 call control structures 

The Media Redirect Attention message signals to the between the VRU and each gateway continue to remain as 

gateway that a Media Redirect Command is following. The they were originally set up. 

gateway then interprets the subsequent inform atioa as part Another specific media redirection implementation may 

of the media redirect protocol instead of as some type of be to use functions (e.g., CallJoin and Calllnvite) described 

DTMF message. There are two primary Media Redirect 50 m sec tion 8.4.3 of the H323 specification, entitled Ad-hoc 

Commands: DROP_RTP and NEW_RTP, wherein: conference expansion. While preliminary laboratory tests 

<Media Redirect Command>="9" for DROP_RTP Com- thus far have not allowed the exchange of voice data 

mand between call A and call B in the laboratory, a conference in 

<Media Redirect Command>»"5" for NEW_RTP Com- between call A and call B has successfully been established, 

mand 55 Therefore the Ad-hoc conference expansion functions may 

Referring to message protocol 940 in FIG. 7, assume that also represent a viable approach for media redirection, 

there are two separate calls, A & B, already set up between Depending on the specific application, a packet VRU 

a first gateway 946 and the VRU, and between the VRU and according to the present invention may provide many dif- 

a second gateway 948, as discussed hereinabove. VRU ferent enhanced services to users linked to the network, 

application 942 initiates media redirection by issuing media 60 including voice messaging, email (containing at least one of: 

redirect command 950 to VoIP driver 944 inside the VRU. voice, audio and data), automated collect calling, intema- 

VdIP driver 944 then handles the detailed protocol of send- tional callback, prepaid calling card, postpaid calling card, 

ing Media Redirect Messages to the gateways to accomplish store & forward, one number, find me, follow me, 800/900 

the media redirection. First VoIP driver 944 sends DROP_ service, automated customer service, automated agents or 

RTP A Message 952 to gateway 946 to command gateway 65 attendants, enhanced fax, voice activated dialing, prepaid & 

946 to drop the media stream between gateway 946 and the postpaid wireless, conferencing, and other enhanced ser- 

VRU. Similarly, VoIP driver 944 sends DROP__RTP B vices. These services may be voice services, similar to the 



04/26/2004, EAST Version: 1.4.1 



US 6,404,746 Bl 

21 22 

services provided by synchronous VRUs, or may be multi- of which are intended within the scope of the present 

media services, capable of handling any combination of invention. For example, devices with wireless, satellite or 

voice, video and data (e.g., text). cable interfaces may be linked to the packet network, and 

It is understood that a specific implementation of a packet may communicate with and utilize the enhanced services of 

VRU may be accomplished in hardware or software or a 5 me packet VRU. 

combination thereof. It is further understood that packet Furthermore while a PSTN may be shown as being 

routing controlled by the packet VRU generally enables div \ dcd mto different sections in the figures for ease of 

- *f • * V™. ™n- ™*„ ™f<>™«„„ nn A explanation, it is understood that the sections may all be part 

point-to-point connections, multi-party conferencing, and *\ » . , , ™™ T ... J „ 

I a \ a \ til ■ * f~A v io u rt Z ™„ of the same nationwide or global PSTN, with some areas 

broadcast as required. In this way. for example, large con- ... . .. . , ... ^ ' . „ ^ 

r . . i , . , J, f ' ; « accessible locally with little or no variable cost, and some 

ference calls may be enabled, or a feed from the conference 10 ' , , 4 , • Ji ;« 

, van>3 ^ajr ^ , areas accessible by long distance at a variable cost m 

may be broadcast to facilitate a radio talk show. It is further additkm tQ the ^ fixed ^ access 

understood that consistent with the present invention, the Although the present invention and its advantages have 
packet VRU may be either collocated with a gateway (on the been described i n detail, it should be understood that various 
packet side) or a gatekeeper, or distant therefrom. While not changes, substitutions and alterations can be made herein 
a preferred embodiment in the long term, a packet VRU may 15 without departing from the spirit and scope of the invention 
also comprise a switched interface to, for example, a PSTN. as defined by the appended claims. Moreover, the scope of 
It is further understood that the exact order of many of the the present application is not intended to be limited to the 
steps outlined in the methods discussed herein may be particular embodiments of the process, machine, 
altered, and such alterations are intended to be within the manufacture, composition of matter, means, methods and 
scope of the present invention. For example, redirected RTP 20 steps described in the specification. As one of ordinary skill 
streams may be set up before or after the original RTP in the art will readily appreciate from the disclosure of the 
streams are torn down. As another example, when connect- present invention, processes, machines, manufacture, com- 
ing multiple parties, all the H.323 calls may first be set up, positions of matter, means, methods, or steps, presently 
followed by the setup of the RTP streams, or each H.323 call existing or later to be developed that perform substantially 
and RTP stream pair for a specific party may be set up, 25 same function or achieve substantially the .same result as 
followed by the setup for another party. As another example, the corresponding embodiments described herein may be 

more than one command may be sent before waiting for the *?™ dm Z to m ° P'? 8 ™ 1 ^^I^l 

J: , i j , a appended claims are intended to include within their scope 

corresponding acknowledge return message. As yet another y * c t r - 

example, one RTP strearn may be completely redirected, such P rocesses ' m ^ mes > manufaClUre> composibons of 

then toe other RTP stream redirected, or commands may be 30 ml "f r > mea f-. me f h . ods > or ste P s " 

, . ,. J TVTTi * t What is claimed is: 

alternated in some manner in redirecting the RTP streams. In . . _ . , _ 

.... c t . . c , . 1. A method for redirecting media m an asynchronous 

addition, some of the specific commands, especially com- 6 . J . 

maids in a custom implementation (e.g., !, 5 and 9), may be P«f*" ° et ™>* »* » s ^ tem asynchronously connected to 

changed and still be ^thin the scope of the present inven- siud nctwo ^ " ethod °° m P™ n g : . 

^ 35 establishing a first call between a first device and said 

In yet another alternative embodiment, for some applica- svstem via s ^ d P a ^ 1 network > wherein said first call 

lions it may be usefull to direct the control calls to the packet comprises a first call control structure and a first media 

VRU as discussed hereinabove, but to immediately direct stream; 

the media stream to the destination, instead of first directing establishing a second call between said system and a 

the media stream to the VRU and then redirecting it to the 40 second device via said packet network, wherem said 

destination. second call comprises a second call control structure 

It is further understood that while the primary standard ^ a second media stream; 

discussed above is H.323, other standards may be present on signaling said first device to redirect said first media 

a packet network and are intended to be within the scope of stream to said second device; and 

the present invention. For example, Session Initiation Pro- 45 signaling said second device to redirect said second media 

tocol ("SIP"), Simple Gateway Control Protocol ("SGCP") stream to said first device, wherein said first and second 

and Media Gateway Controller Protocol ("MEGACO") may call control structures are not redirected away from said 

alternatively be used to implement media redirection. Each system, and said system does not receive said media 

standard has somewhat different functionality, and each has while said media streams are redirected, 

certain advantages and disadvantages with respect to other 50 2. The method of claim 1, wherein said first and second 

the standards. devices are network gateways. 

It is further understood that while the core functionality of 3. The method of claim 1, wherein at least one of said first 

a packet VRU is enhancing voice communications, it may be and second devices is an Internet Protocol phone, 

possible for any device connected to the packet network may 4. The method of claim 1, wherein said establishing said 

communicate with and utilize the enhanced services of the 55 first call comprises receiving said first call from said first 

packet VRU (e.g., a fax machine, data modem or telephone device. 

via a gateway, or computers or other terminals connected to 5. The method of claim 1, wherein said establishing said 

the packet network and executing H.323 protocols). It is second call comprises initiating said second call with said 

further understood that, to take advantage of the present second device. 

invention, a computer user typically requires a multimedia- 60 6. The method of claim 5, wherein said second call is 

grade computer, including speakers, sound card, micro- initiated in response to information provided in said first 

phone and fall duplex voice-enabling software. call. 

Alternatively, the computer may also include a video input 7. The method of claim 1, wherein said first and second 

useful, e.g., in video conferencing. Alternatively, the com- calls are H.323 standard calls. 

puter user may use a lower capability computer in combi- 65 8. The method of claim 7, wherein said first and second 

nation with a traditional telephone. It is further understood call control structures each comprise G.931 standard call 

that there are many ways to connect to a packet network, all signaling and H.245 standard call control. 
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9. The method of claim 7, wherein said media streams are 
real-time protocol media streams. 

10. The method of claim 7, wherein said media streams 
are real-time control protocol media streams. 

11. The method of claim 1, wherein said packet network 
is the Internet. 

12. The method of claim 1, wherein said media is voice. 

13. The method of claim 1, wherein said media is selected 
from the group consisting of: voice, video, multimedia, and 
combinations thereof. 

14. The method of claim 1, wherein said first and second 
media streams comprise the same data type and data rate. 

15. The method of claim 1, wherein said first and second 
media streams comprise different data types and data rates. 

16. The method of claim 1, wherein call context for said 
first and second calls is retained by said system. 

17. The method of claim 1, further comprising: 
tearing down said first media stream redirected to said 

second device; 
tearing down said second media stream redirected to said 
first device; 

tearing down said second call control structure; and 
reestablishing said first media stream between said first 
device and said system, wherein said first call is recon- 
nected as before said redirect of said first media stream. 

18. The method of claim 17, further comprising: 
establishing a third call between said system and a third 

device via said packet network, wherein said third call 
comprises a third call control structure and a third 
media stream; 

signaling said first device to redirect said first media 

stream to said third device; and 
signaling said third device to redirect said third media 

stream to said first device; wherein said first and third 

call control structures are not redirected away from said 

system. 

19. The method of claim 18, wherein said tearing down of 
said of said first and second media streams and said second 
call control structure are in response to a user input indica- 
tion message received from said first device. 

20. The method of claim 1, further comprising: 
tearing down said first media stream redirected to said 

second device; 
tearing down said second media stream redirected to said 
first device; 

tearing down said first call control structure; and 
tearing down said second call control structure. 

21. The method of claim 1, further comprising: 
tearing down said first media stream redirected to said 

second device; 
tearing down said second media stream redirected to said 
first device; 

reestablishing said first media stream between said first 
device and said system, wherein said first call is recon- 
nected as before said redirect of said first media stream; 
and 

reestablishing said second media stream between said 
system and said second device, wherein said second 
call is reconnected as before said redirect of said 
second media stream. 

22. The method of claim 1, further comprising: 
establishing a third call between said system and a third 

device via said packet network, wherein said third call 
comprises a third call control structure and a third 
media stream; 
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signaling said first device to replicate said first media 
stream to send data to said third device in addition to 
said second device; 

signaling said second device to replicate said second 
5 media stream to send data to said third device in 
addition to said first device; 

signaling said third device to redirect said third media 
stream to said first device; and 
10 signaling said third device to replicate said third media 
stream to send data to said second device in addition to 
said first device, wherein said third call control struc- 
ture is not redirected away from said system. 

23. The method of claim 1, wherein user input indication 
5 messages are transmitted out-of-band from said media 

streams. 

24. The method of claim 23, wherein said user input 
indication messages are transmitted in at least one of said 
call control structures. 

2() 25. The method of claim 23, wherein said user input 
indication messages comprise dual tone multiple frequency 
(DTMF) signal messages. 

26. The method of claim 23, wherein said user input 
indication messages are generated by said first device. 
25 27. The method of claim 23, further comprising: 

receiving said user input indication messages from said 
first device. 

28. The method of claim 27, further comprising: 
forwarding said user input indication messages to said 

30 second device. 

29. The method of claim 1, wherein said system is a 
packet voice response unit. 

30. The system of claim 29, wherein said packet voice 
response unit provides an enhanced service selected from 

35 the group consisting of: prepaid calling card service, post- 
paid calling card service, collect calling service, interna- 
tional callback service, one number service, voice activated 
dialing service, conferencing service, and combinations 
thereof. 

40 31. The method of claim 1, wherein said system is 
asynchronously connected to said packet network via an 
Ethernet connection. 

32. A system for redirecting media in an asynchronous 
packet network, said system comprising: 

45 an asynchronous interface to said packet network; 

means for establishing a first call with a first device via 
said packet network, wherein said first call comprises a 
first call control structure and a first media stream; 

50 means for establishing a second call with a second device 
via said packet network, wherein said second call 
comprises a second call control structure and a second 
media stream; 

means for signaling said first device to redirect said first 
55 media stream to said second device; and 

means for signaling said second device to redirect said 
second media stream to said first device, wherein said 
first and second call control structures are not redi- 
rected away from said system, and said system does not 
60 receive said media while said media streams are redi- 
rected. 

33. The system of claim 32, wherein said asynchronous 
interface is an Ethernet connection. 

34. The system of claim 32, wherein said first and second 
65 devices are network gateways. 

35. The system of claim 32, wherein at least one of said 
first and second devices is an Internet Protocol (IP) phone. 
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36. The system of claim 32, wherein said means for 
establishing said first call comprises means for receiving 
said first call from said first device. 

37. The system of claim 32, wherein said means for 
establishing said second call comprises means for initiating 
said second call with said second device. 

38. The method of claim 37, wherein said second call is 
initiated in response to information provided in said first 
call. 

39. The system of claim 32, wherein said first and second 
calls are H.323 standard calls. 

40. The system of claim 39, wherein said first and second 
call control structures each comprise G.931 standard call 
signaling and H.245 standard call control. 

41. The system of claim 40, wherein said media streams 
are real-time protocol media streams. 

42. The system of claim 40, wherein said media streams 
are real-time control protocol media streams. 

43. The system of claim 32, wherein said packet network 
is the Internet. 

44. The system of claim 32, wherein said media is voice. 

45. The system of claim 32, wherein said media is 
selected from the group consisting of: voice, video, 
multimedia, and combinations thereof. 

46. The system of claim 32, wherein said first and second 
media streams comprise the same data type and data rate. 

47. The system of claim 32, wherein said first and second 
media streams comprise different data types and data rates. 

48. The system of claim 32, wherein call context for said 
first and second calls is retained by said system. 

49. The system of claim 32, further comprising: 
means for tearing down said first media stream redirected 

to said second device; 

means for tearing down said second media stream redi- 
rected to said first device; 

means for tearing down said second call control structure; 
and 

means for reestablishing said first media stream between 
said first device and said system, wherein said first call 
is reconnected as before said redirect of said first media 
stream. 

50. The system of claim 49, further comprising: 
means for establishing a third call between said system 

and a third device via said packet network, wherein said 

third call comprises a third call control structure and a 

third media stream; 
means for signaling said first device to redirect said first 

media stream to said third device; and 
means for signaling said third device to redirect said third 

media stream to said first device; wherein said first and 

third call control structures are not redirected away 

from said system. 

51. The system of claim 50, wherein said means for 
tearing down of said of said first and second media streams 
and said second call control structure respond to a user input 
indication message received from said first device. 

52. The system of claim 32, further comprising: 
means for tearing down said first media stream redirected 

to said second device; 

means for tearing down said second media stream redi- 
rected to said first device; 

means for tearing down said first call control structure; 
and 

means for tearing down said second call control structure. 
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53. The system of claim 32, further comprising: 
means for tearing down said first media stream redirected 

to said second device; 

means for tearing down said second media stream redi- 
rected to said first device; 

means for reestablishing said first media stream between 
said first device and said system, wherein said first call 
is reconnected as before said redirect of said first media 
stream; and 

means for reestablishing said second media stream 
between said system and said second device, wherein 
said second call is reconnected as before said redirect 
of said second media stream. 

54. The system of claim 32, further comprising: 
means for establishing a third call between said system 

and a third device via said packet network, wherein said 

third call comprises a third call control structure and a 

third media stream; 
means for signaling said first device to replicate said first 

media stream to send data to said third device in 

addition to said second device; 
means for signaling said second device to replicate said 

second media stream to send data to said third device 

in addition to said first device; 
means for signaling said third device to redirect said third 

media stream to said first device; and 
means for signaling said third device to replicate said 

third media stream to send data to said second device 

in addition to said first device, wherein said third call 

control structure is not redirected away from said 

system. 

55. The system of claim 32, wherein user input indication 
messages are transmitted out-of-band from said media 
streams. 

56. The system of claim 55, wherein said user input 
indication messages are transmitted in at least one of said 
call control structures. 

57. The system of claim 55, wherein said user input 
indication messages comprise dual tone multiple frequency 
(DTMF) signal messages. 

58. The system of claim 55, wherein said user input 
indication messages are generated by said first device. 

59. The system of claim 55, further comprising: 
means for receiving said user input indication messages 

from said first device. 

60. The system of claim 59, further comprising: 
means for forwarding said user input indication messages 

to said second device. 

61. The system of claim 32, wherein said system is a 
packet voice response unit. 

62. The system of claim 61, wherein said packet voice 
response unit provides an enhanced service selected from 
the group consisting of: prepaid calling card service, post- 
paid calling card service, collect calling service, interna- 
tional callback service, one number service, voice activated 
dialing service, conferencing service, and combinations 
thereof. 

63. A computer program product having a computer 
readable medium with computer program logic recorded 
thereon for use in a system asynchronously connected to a 
packet network for redirecting media in said asynchronous 
packet network, said computer program product comprising: 

code for establishing a first call with a first device via said 
packet network, wherein said first call comprises a first 
call control structure and a first media stream; 
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code for establishing a second call with a second device 
via said packet network, wherein said second call 
comprises a second call control structure and a second 
media stream; 

code for signaling said first device to redirect said first 5 
media stream to said second device; and 

code for signaling said second device to redirect said 
second media stream to said first device, wherein said 
first and second call control structures are not redi- 
rected away from said system, and said system does not 10 
receive said media while said media streams are redi- 
rected. 

64. The computer program product of claim 63, wherein 
said system is a packet voice response unit. 

65. The computer program product of claim 64, wherein 15 
said packet voice response unit provides an enhanced ser- 
vice selected from the group consisting of: prepaid calling 
card service, postpaid calling card service, collect calling 
service, international callback service, one number service, 
voice activated dialing service, conferencing service, and 20 
combinations thereof. 

66. The computer program product of claim 63, wherein 
said system is asynchronously connect to said packet net- 
work via an Ethernet connection. 

67. The computer program product of claim 63, wherein 25 
said first and second devices are network gateways. 

68. The computer program product of claim 63, wherein 
at least one of said first and second devices is an Internet 
Protocol (IP) phone. 

69. The computer program product of claim 63, wherein 30 
said code for establishing said first call comprises code for 
receiving said first call from said first device. 

70. The computer program product of claim 63, wherein 
said code for establishing said second call comprises code 
for initiating said second call with said second device. 35 

71. The method of claim 70, wherein said second call is 
initiated in response to information provided in said first 
call. 

72. The computer program product of claim 63, wherein 
said first and second calls are H.323 standard calls. 40 

73. The computer program product of claim 72, wherein 
said first and second call control structures each comprise 
G.931 standard call signaling and H.245 standard call con- 
trol. 

74. The computer program product of claim 72, wherein 45 
said media streams are real-time protocol media streams, 

75. The computer program product of claim 72, wherein 
said media streams are real-time control protocol media 
streams. 

76. The computer program product of claim 63, wherein 50 
said packet network is the Internet. 

77. The computer program product of claim 63, wherein 
said media is voice. 

78. The computer program product of claim 63, wherein 
said media is selected from the group consisting of: voice, 55 
video, multimedia, and combinations thereof. 

79. The computer program product of claim 63, wherein 
said first and second media streams comprise the same data 
type and data rate. 

80. The computer program product of claim 63, wherein 60 
said first and second media streams comprise different data 
types and data rates. 

81. The computer program product of claim 63, wherein 
call context for said first and second calls is retained by said 
system. 65 

82. The computer program product of claim 63, further 

comprising: 
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code for tearing down said first media stream redirected to 

said second device; 
code for tearing down said second media stream redi- 
rected to said first device; 
code for tearing down said second call control structure; 
and 

code for reestablishing said first media stream between 
said first device and said system, wherein said first call 
is reconnected as before said redirect of said first media 
stream. 

83. The computer program product of claim 82, further 
comprising: 

code for establishing a third call between said system and 
a third device via said packet network, wherein said 
third call comprises a third call control structure and a 
third media stream; 
code for signaling said first device to redirect said first 

media stream to said third device; and 
code for signaling said third device to redirect said third 
media stream to said first device; wherein said first and 
third call control structures are not redirected away 
from said system. 

84. The computer program product of claim 83, wherein 
said code for tearing down of said of said first and second 
media streams and said second call control structure respond 
to a user input indication message received from said first 
device. 

85. The computer program product of claim 63, further 
comprising: 

code for tearing down said first media stream redirected to 

said second device; 
code for tearing down said second media stream redi- 
rected to said first device; 
code for tearing down said first call control structure; and 
code for tearing down said second call control structure. 

86. The computer program product of claim 63, further 
comprising: 

code for tearing down said first media stream redirected to 

said second device; 
code for tearing down said second media stream redi- 
rected to said first device; 
code for reestablishing said first media stream between 
said first device and said system, wherein said first call 
is reconnected as before said redirect of said first media 
stream; and 

code for reestablishing said second media stream between 
said system and said second device, wherein said 
second call is reconnected as before said redirect of 
said second media stream. 

87. The computer program product of claim 63, further 
comprising: 

code for establishing a third call between said system and 
a third device via said packet network, wherein said 
third call comprises a third call control structure and a 
third media stream; 
code for signaling said first device to replicate said first 
media stream to send data to said third device in 
addition to said second device; 
code for signaling said second device to replicate said 
second media stream to send data to said third device 
in addition to said first device; 
code for signaling said third device to redirect said third 

media stream to said first device; and 
code for signaling said third device to replicate said third 
media stream to send data to said second device in 
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addition to said first device, wherein said third call 
control structure is not redirected away from said 
system. 

88. The computer program product of claim 63, herein 
user input indication messages are transmitted out-of-band 
from said media streams. 

89. The computer program product of claim 88, wherein 
said user input indication messages are transmitted in at least 
one of said call control structures. 

90. The computer program product of claim 88, wherein 
said user input indication messages comprise dual tone 
multiple frequency (DTMF) signal messages. 

91. The computer program product of claim 88, wherein 
said user input indication messages are generated by said 
first device. 

92. The computer program product of claim 88, further 
comprising: 

code for receiving said user input indication messages 
from said first device. 

93. The computer program product of claim 92, further 
comprising: 

code for forwarding said user input indication messages to 
said second device. 

94. A system for redirecting media in an asynchronous 
packet network, said system comprising: 

an asynchronous interface to said packet network; 

a call control server, wherein said call control server sets 
up call control structures to communicate with devices 
in said packet network via said asynchronous interface 
for controlling media streams from and to said devices; 

a voice media server communicating with said call control 
server, wherein said call control server uses said call 
control structures to establish media streams between 
said devices and said voice media server via said 
asynchronous interface; and 

an application server communicating with said call con- 
trol server and said voice media server, wherein said 
application server instructs said call control server to 
redirect said media streams to be transmitted directiy 
between said devices without passing through said 
voice media server, and wherein said call control 
structures are retained between said devices and said 
voice media server, and said voice media server does 
not receive said media while said media streams are 
redirected. 

95. The system of claim 94, wherein said call control 
structures each comprise G.931 standard call signaling and 
H.245 standard call control. 

96. The system of claim 94, wherein said media streams 
are real-time protocol media streams. 

97. The system of claim 94, wherein said media streams 
are real-time control protocol media streams. 

98. The system of claim 94, wherein said packet network 
is the Internet. 

99. The system of claim 94, wherein said media is voice. 

100. The system of claim 94, wherein said media is 
selected from the group consisting of: voice, video, 
multimedia, and combinations thereof. 

101. The system of claim 94, wherein said first and second 
media streams comprise the same data type and data rate. 

102. The system of claim 94, wherein said first and second 
media streams comprise different data types and data rates. 

103. The system of claim 94, wherein user input indica- 
tion messages are transmitted out-of-band from said media 
streams. 

104. The system of claim 103, wherein said user input 
indication messages are transmitted in at least one of said 
call control structures. 



105. The system of claim 103, wherein said user input 
indication messages comprise dual tone multiple frequency 
(DTMF) signal messages. 

106. The system of claim 103, wherein said user input 
indication messages are generated one of said devices. 

107. The system of claim 94, wherein said system is a 
packet voice response unit. 

108. The system of claim 107, wherein said packet voice 
response unit provides an enhanced service selected from 
the group consisting of: prepaid calling card service, post- 
paid calling card service, collect calling service, interna- 
tional callback service, one number service, voice activated 
dialing service, conferencing service, and combinations 
thereof. 

109. The system of claim 94, wherein said asynchronous 
interface is an Ethernet connection. 

110. The system of claim 94, wherein said devices are 
network gateways. 

111. The system of claim 94, wherein at least one of said 
devices is an Internet Protocol (IP) phone. 

112. A method for redirecting media in an asynchronous 
packet network by a system asynchronously connected to 
said packet network, said method comprising: 

establishing a first call between a first device and said 
system via said packet network, wherein said first call 
comprises a first call control structure and a first media 
stream; 

establishing a second call between said system and a 
second device via said packet network, wherein said 
second call comprises a second call control structure 
and a second media stream; 
signaling said first device to redirect said first media 

stream to said second device; and 
signaling said second device to redirect said second media 
stream to said first device, wherein said first and second 
call control structures are not redirected away from said 
system, and said system continues to receive a copy of 
said media streams while said media streams are redi- 
rected. 

113. The method of claim 112, wherein said first and 
40 second devices are network gateways. 

114. The method of claim 112, wherein at least one of said 
first and second devices is an Internet Protocol phone. 

115. The method of claim 112, wherein said establishing 
said first call comprises receiving said first call from said 
first device. 

116. The method of claim 112, wherein said establishing 
said second call comprises initiating said second call with 
said second device. 

117. The method of claim 116, wherein said second call 
is initiated in response to information provided in said first 
call. 

118. The method of claim 112, wherein said first and 
second calls are H.323 standard calls. 

119. The method of claim 118, wherein said first and 
second call control structures each comprise G.931 standard 
call signaling and H.245 standard call control. 

120. The method of claim 118, wherein said media 
streams are real-time protocol media streams. 

121. The method of claim 118, wherein said media 
streams are real-time control protocol media streams. 

122. The method of claim 112, wherein said packet 
network is the Internet. 

123. The method of claim 112, wherein said media is 
voice. 

124. The method of claim 112, wherein said media is 
selected from the group consisting of: voice, video, 
multimedia, and combinations thereof. 
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125. The method of claim 112, wherein said first and 
second media streams comprise the same data type and data 
rate. 

126. The method of claim 112, wherein said first and 
second media streams comprise different data types and data 
rates. 

127. The method of claim 112, wherein call context for 
said first and second calls is retained by said system. 

128. The method of claim 112, further comprising: 
tearing down said first media stream redirected to said 

second device; 
tearing down said second media stream redirected to said 
first device; 

tearing down said second call control structure; and 
reestablishing said first media stream between said first 
device and said system, wherein said first call is recon- 
nected as before said redirect of said first media stream. 

129. The method of claim 128, further comprising: 
establishing a third call between said system and a third 

device via said packet network, wherein said third call 
comprises a third call control structure and a third 
media stream; 

signaling said first device to redirect said first media 

stream to said third device; and 
signaling said third device to redirect said third media 

stream to said first device; wherein said first and third 

call control structures are not redirected away from said 

system. 

130. The method of claim 129, wherein said tearing down 
of said of said first and second media streams and said 
second call control structure are in response to a user input 
indication message received from said first device. 

131. The method of claim 112, further comprising: 
tearing down said first media stream redirected to said 

second device; 
tearing down said second media stream redirected to said 
first device; 

tearing down said first call control structure; and 
tearing down said second call control structure. 

132. The method of claim 112, further comprising: 
tearing down said first media stream redirected to said 

second device; 
tearing down said second media stream redirected to said 
first device; 

reestablishing said first media stream between said first 
device and said system, wherein said first call is recon- 
nected as before said redirect of said first media stream; 
and 

reestablishing said second media stream between said 
system and said second device, wherein said second 
call is reconnected as before said redirect of said 
second media stream. 

133. The method of claim 112, further comprising: 
establishing a third call between said system and a third 

device via said packet network, wherein said third call 
comprises a third call control structure and a third 
media stream; 

signaling said first device to replicate said first media 

stream to send data to said third device in addition to 

said second device; 
signaling said second device to replicate said second 

media stream to send data to said third device in 

addition to said first device; 
signaling said third device to redirect said third media 

stream to said first device; and 
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signaling said third device to replicate said third media 
stream to send data to said second device in addition to 
said first device, wherein said third call control struc- 
ture is not redirected away from said system. 
5 134. The method of claim 112, wherein user input indi- 
cation messages are transmitted out-of-band from said 
media streams. 

135. The method of claim 134, wherein said user input 
indication messages are transmitted in at least one of said 

10 call control structures. 

136. The method of claim 134, wherein said user input 
indication messages comprise dual tone multiple frequency 
(DTMF) signal messages. 

137. The method of claim 134, wherein said user input 
15 indication messages are generated by said first device. 

138. The method of claim 134, further comprising: 
receiving said user input indication messages from said 

first device. 

139. The method of claim 138, further comprising: 

20 forwarding said user input indication messages to said 
second device. 

140. The method of claim 112, wherein said system is a 
packet voice response unit. 

141. The system of claim 140, wherein said packet voice 
25 response unit provides an enhanced service selected from 

the group consisting of: prepaid calling card service, post- 
paid calling card service, collect calling service, interna- 
tional callback service, one number service, voice activated 
dialing service, conferencing service, and combinations 
30 thereof. 

142. The method of claim 112, wherein said system is 
asynchronously connected to said packet network via an 
Ethernet connection. 

143. A system for redirecting media in an asynchronous 
35 packet network, said system comprising: 

an asynchronous interface to said packet network; 

means for establishing a first call with a first device via 
said packet network, wherein said first call comprises a 
first call control structure and a first media stream; 

40 

means for establishing a second call with a second device 
via said packet network, wherein said second call 
comprises a second call control structure and a second 
media stream; 

45 means for signaling said first device to redirect said first 
media stream to said second device; and 
means for signaling said second device to redirect said 
second media stream to said first device, wherein said 
first and second call control structures are not redi- 

50 rected away from said system, and said system contin- 
ues to receive a copy of said media streams while said 
media streams are redirected. 

144. The system of claim 143, wherein said first and 
second devices are network gateways. 

55 145. The system of claim 143, wherein at least one of said 

first and second devices is an Internet Protocol (IP) phone. 
146. The system of claim 143, wherein said means for 

establishing said first call comprises means for receiving 

said first call from said first device. 
60 147. The system of claim 143, wherein said means for 

establishing said second call comprises means for initiating 

said second call with said second device. 

148. The method of claim 147, wherein said second call 
is initiated in response to information provided in said first 

65 call. 

149. The system of claim 143, wherein said first and 
second calls are H.323 standard calls. 
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150. The system of claim 149, wherein said first and 
second call control structures each comprise G.931 standard 
call signaling and H.245 standard call control. 

151. The system of claim 150, wherein said media streams 
are real-time protocol media streams, 

152. The system of claim 150, wherein said media streams 
are real-time control protocol media streams. 

153. The system of claim 143, wherein said packet 
network is the Internet. 

154. The system of claim 143, wherein said media is 
voice. 

155. The system of claim 143, wherein said media is 
selected from the group consisting of: voice, video, 
multimedia, and combinations thereof. 

156. The system of claim 143, wherein said first and 
second media streams comprise the same data type and data 
rate. 

157. The system of claim 143, wherein said first and 
second media streams comprise different data types and data 
rates. 

158. The system of claim 143, wherein call context for 
said first and second calls is retained by said system. 

159. The system of claim 143, further comprising: . 
means for tearing down said first media stream redirected 

to said second device; 

means for tearing down said second media stream redi- 
rected to said first device; 

means for tearing down said second call control structure; 
and 

means for reestablishing said first media stream between 
said first device and said system, wherein said first call 
is reconnected as before said redirect of said first media 
stream. 

160. The system of claim 159, further comprising: 
means for establishing a third call between said system 

and a third device via said packet network, wherein said 

third call comprises a third call control structure and a 

third media stream; 
means for signaling said first device to redirect said first 

media stream to said third device; and 
means for signaling said third device to redirect said third 

media stream to said first device; wherein said first and 

third call control structures are not redirected away 

from said system. 

161. The system of claim 160, wherein said means for 
tearing down of said of said first and second media streams 
and said second call control structure respond to a user input 
indication message received from said first device. 

162. The system of claim 143, further comprising: 
means for tearing down said first media stream redirected 

to said second device; 

means for tearing down said second media stream redi- 
rected to said first device; 

means for tearing down said first call control structure; 
and 

means for tearing down said second call control structure. 

163. The system of claim 143, further comprising: 
means for tearing down said first media stream redirected 

to said second device; 

means for tearing down said second media stream redi- 
rected to said first device; 

means for reestablishing said first media stream between 
said first device and said system, wherein said first call 
is reconnected as before said redirect of said first media 
stream; and 
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means for reestablishing said second media stream 
between said system and said second device, wherein 
said second call is reconnected as before said redirect 
of said second media stream. 

164. The system of claim 143, further comprising: 
means for establishing a third call between said system 

and a third device via said packet network, wherein said 

third call comprises a third call control structure and a 

third media stream; 
means for signaling said first device to replicate said first 

media stream to send data to said third device in 

addition to said second device; 
means for signaling said second device to replicate said 

second media stream to send data to said third device 

in addition to said first device; 
means for signaling said third device to redirect said third 

media stream to said first device; and 
means for signaling said third device to replicate said 

third media stream to send data to said second device 

in addition to said first device, wherein said third call 

control structure is not redirected away from said 

system. 

165. The system of claim 143, wherein user input indi- 
cation messages are transmitted out-of-band from said 
media streams. 

166. The system of claim 165, wherein said user input 
indication messages are transmitted in at least one of said 
call control structures. 

167. The system of claim 165, wherein said user input 
indication messages comprise dual tone multiple frequency 
(DTMF) signal messages. 

168. The system of claim 165, wherein said user input 
indication messages are generated by said first device. 

169. The system of claim 165, further comprising: 
means for receiving said user input indication messages 

from said first device. 

170. The system of claim 169, further comprising: 
means for forwarding said user input indication messages 

to said second device. 

171. The system of claim 143, wherein said system is a 
packet voice response unit. 

172. The system of claim 171, wherein said packet voice 
response unit provides an enhanced service selected from 
the group consisting of: prepaid calling card service, post- 
paid calling card service, collect calling service, interna- 
tional callback service, one number service, voice activated 
dialing service, conferencing service, and combinations 
thereof. 

173. The system of claim 143, wherein said asynchronous 
interface is an Ethernet connection. 

174. A computer program product having a computer 
readable medium with computer program logic recorded 
thereon for use in a system asynchronously connected to a 
packet network for redirecting media in said asynchronous 
packet network, said computer program product comprising: 

code for establishing a first call with a first device via said 
packet network, wherein said first call comprises a first 
call control structure and a first media stream; 

code for establishing a second call with a second device 
via said packet network, wherein said second call 
comprises a second call control structure and a second 
media stream; 

code for signaling said first device to redirect said first 
media stream to said second device; and 

code for signaling said second device to redirect said 
second media stream to said first device, wherein said 
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first and second call control structures are not redi- 
rected away from said system, and said system contin- 
ues to receive a copy of said media streams while said 
media streams are redirected. 

175. The computer program product of claim 174, 
wherein said first and second devices are network gateways. 

176. The computer program product of claim 174, 
wherein at least one of said first and second devices is an 
Internet Protocol (IP) phone. 

177. The computer program product of claim 174, 
wherein said code for establishing said first call comprises 
code for receiving said first call from said first device. 

178. The computer program product of claim 174, 
wherein said code for establishing said second call com- 
prises code for initiating said second call with said second 
device. 

179. The method of claim 178, wherein said second call 
is initiated in response to information provided in said first 
call. 

180. The computer program product of claim 174, 
wherein said first and second calls are H.323 standard calls. 

181. The computer program product of claim 180, 
wherein said first and second call control structures each 
comprise G.931 standard call signaling and H.245 standard 
call control. 

182. The computer program product of claim 180, 
wherein said media streams are real-time protocol media 
streams. 

183. The computer program product of claim 180, 
wherein said media streams are real-time control protocol 
media streams. 

184. The computer program product of claim 174, 
wherein said packet network is the Internet. 

185. The computer program product of claim 174, 
wherein said media is voice. 

186. The computer program product of claim 174, 
wherein said media is selected from the group consisting of: 
voice, video, multimedia, and combinations thereof. 

187. The computer program product of claim 174, 
wherein said first and second media streams comprise the 
same data type and data rate. 

188. The computer program product of claim 174, 
wherein said first and second media streams comprise dif- 
ferent data types and data rates. 

189. The computer program product of claim 174, 
wherein call context for said first and second calls is retained 
by said system. 

190. The computer program product of claim 174, further 
comprising: 

code for tearing down said first media stream redirected to 
said second device; 

code for tearing down said second media stream redi- 
rected to said first device; 

code for tearing down said second call control structure; 
and 

code for reestablishing said first media stream between 
said first device and said system, wherein said first call 
is reconnected as before said redirect of said first media 
stream. 

191. The computer program product of claim 190, further 
comprising: 

code for establishing a third call between said system and 
a third device via said packet network, wherein said 
third call comprises a third call control structure and a 
third media stream; 

code for signaling said first device to redirect said first 
media stream to said third device; and 
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code for signaling said third device to redirect said third 
media stream to said first device; wherein said first and 
third call control structures are not redirected away 
from said system. 

192. The computer program product of claim 191, 
wherein said code for tearing down of said of said first and 
second media streams and said second call control structure 
respond to a user input indication message received from 
said first device. 

193. The computer program product of claim 174, further 
comprising: , 

code for tearing down said first media stream redirected to 
said second device; 

code for tearing down said second media stream redi- 
rected to said first device; 

code for tearing down said first call control structure; and 

code for tearing down said second call control structure. 

194. The computer program product of claim 174, further 
comprising: 

code for tearing down said first media stream redirected to 
said second device; 

code for tearing down said second media stream redi- 
rected to said first device; 

code for reestablishing said first media stream between 
said first device and said system, wherein said first call 
is reconnected as before said redirect of said first media 
stream; and 

code for reestablishing said second media stream between 
said system and said second device, wherein said 
second call is reconnected as before said redirect of 
said second media stream. 

195. The computer program product of claim 174, further 
comprising: 

code for establishing a third call between said system and 
a third device via said packet network, wherein said 
third call comprises a third call control structure and a 
third media stream; 

code for signaling said first device to replicate said first 
media stream to send data to said third device in 
addition to said second device; 

code for signaling said second device to replicate said 
second media stream to send data to said third device 
in addition to said first device; 

code for signaling said third device to redirect said third 
media stream to said first device; and 

code for signaling said third device to replicate said third 
media stream to send data to said second device in 
addition to said first device, wherein said third call 
control structure is not redirected away from said 
system. 

196. The computer program product of claim 174, 
wherein user input indication messages are transmitted 
out-of-band from said media streams. 

197. The computer program product of claim 196, 
wherein said user input indication messages are transmitted 
in at least one of said call control structures. 

198. The computer program product of claim 196, 
wherein said user input indication messages comprise dual 
tone multiple frequency (DTMF) signal messages. 

199. The computer program product of claim 196, 
wherein said user input indication messages are generated 
by said first device. 

200. The computer program product of claim 196, further 
comprising: 

code for receiving said user input indication messages 
from said first device. 
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201. The computer program product of claim 200, further 
comprising: 

code for forwarding said user input indication messages to 
said second device. 

202. The computer program product of claim 174, 
wherein said system is a packet voice response unit. 

203. The computer program product of claim 202, 
wherein said packet voice response unit provides an 
enhanced service selected from the group consisting of: 
prepaid calling card service, postpaid calling card service, 
collect calling service, international callback service, one 
number service, voice activated dialing service, conferenc- 
ing service, and combinations thereof. 

204. The computer program product of claim 174, 
wherein said system is asynchronously connect to said 
packet network via an Ethernet connection. 

205. A system for redirecting media in an asynchronous 
packet network, said system comprising: 

an asynchronous interface to said packet network; 

a call control server, wherein said call control server sets 
up call control structures to communicate with devices 
in said packet network via said asynchronous interface 
for controlling media streams from and to said devices; 

a voice media server communicating with said call control 
server, wherein said call control server uses said call 
control structures to establish media streams between 
said devices and said voice media server via said 
asynchronous interface; and 

an application server communicating with said call con- 
trol server and said voice media server, wherein said 
application server instructs said call control server to 
redirect said media streams to be transmitted directly 
between said devices without passing through said 
voice media server, and wherein said call control 
structures are retained between said devices and said 
voice media server, and said voice media server con- 
tinues to receive a copy of said media streams while 
said media streams are redirected. 

206. The system of claim 205, wherein said devices are 
network gateways. 

207. The system of claim 205, wherein at least one of said 
devices is an Internet Protocol (IP) phone. 

208. The system of claim 205, wherein said call control 
structures each comprise G.931 standard call signaling and 
H.245 standard call control. 

209. The system of claim 205, wherein said media streams 
are real-time protocol media streams. 

210. The system of claim 205, wherein said media streams 
are real-time control protocol media streams. 

211. The system of claim 205, wherein said packet 
network is the Internet. 

212. The system of claim 205, wherein said media is 
voice. 
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213. The system of claim 205, wherein said media is 
selected from the group consisting of: voice, video, 
multimedia, and combinations thereof. 

214. The system of claim 205, wherein said first and 
5 second media streams comprise the same data type and data 

rate. 

215. The system of claim 205, wherein said first and 
second media streams comprise different data types and data 
rates. 

Q 216. The system of claim 205, wherein user input indi- 
cation messages are transmitted out-of-band from said 
media streams. 

217. The system of claim 216, wherein said user input 
indication messages are transmitted in at least one of said 

1S call control structures. 

218. The system of claim 216, wherein said user input 
indication messages comprise dual tone multiple frequency 
(DTMF) signal messages. 

219. The system of claim 216, wherein said user input 
20 indication messages are generated one of said devices. 

220. The system of claim 205, wherein said system is a 
packet voice response unit. 

221. The system of claim 220, wherein said packet voice 
response unit provides an enhanced service selected from 

2S the group consisting of: prepaid calling card service, post- 
paid calling card service, collect calling service, interna- 
tional callback service, one number service, voice activated 
dialing service, conferencing service, and combinations 
thereof. 

30 222. The system of claim 205, wherein said asynchronous 
interface is an Ethernet connection. 

223. A method for redirecting media in an asynchronous 
packet network by a system asynchronously connected to 
said packet network, said method comprising: 
35 establishing a first call between a first device and said 
system via said packet network, wherein said first call 
comprises a first call control structure and a first media 
stream; 

establishing a second call between said system and said 
40 second device via said packet network, wherein said 
second call comprises a second call control structure 
and a second media stream; 
signaling said first device to redirect said first media 
stream to a second device, wherein said first call control 
45 structure is retained between said first device and said 
system, and 

signaling said second device to redirect said second media 
stream to said first device, wherein said second call 
control structure is retained between said system and 
50 said second device, and said system continues to 
receive a copy of said media streams while said media 
streams are redirected. 

***** 
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